Re: CNAME aliases for wkd.keys.openpgp.org and X.509 certificates [was: Re: WKD for GitHub pages]

2021-01-16 Thread Vincent Breitmoser via Gnupg-users


> Now I'm a bit confused :O
> I thought WKD can be used with your own webserver. So why do I have to 
> make a CNAME recort pointing to "wkd.keys.openpgp.org"?
> 
> Or did I understand anything wrong?

Sorry, that was confusing without context. Yes, WKD is bound to the domain of
the email address, and as such it will typically be hosted together with the
email server itself, or at least by the same entity.

Using the advanced WKD method, it's possible to "outsource" hosting using
a CNAME, and keys.o.o will do the rest:

https://keys.openpgp.org/about/usage#wkd-as-a-service

But this is only a shortcut for convenience. WKD works best when it is run
decentralized by the email hosters themselves.

 - V

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: CNAME aliases for wkd.keys.openpgp.org and X.509 certificates [was: Re: WKD for GitHub pages]

2021-01-16 Thread Stefan Claas via Gnupg-users
On Sat, Jan 16, 2021 at 12:55 PM Stefan Claas
 wrote:
>
> On Sat, Jan 16, 2021 at 12:52 PM Stefan Claas
>  wrote:
> >
> > On Sat, Jan 16, 2021 at 10:32 AM Juergen Bruckner via Gnupg-users
> >  wrote:
> > >
> > > Hello Group!
> >
> > > BTW ... do any of you know a tutorial to set up WKD for 'Dummies'?
> >
> > Hi Juergen,
> >
> > me as a Windows DAU (Dümmster Anzunehmnder User) used the direct-method:
>
> [EDIT]
>
> > Create in your web server's root directory the following:
> > a directory '.well-known' and in that
> > a folder named 'openpgpkey' put in that folder another folder named: 'hu'.

[EDITT #2] With root directory I mean where you have stored your html content
which shows up when someone is visiting your site.

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: CNAME aliases for wkd.keys.openpgp.org and X.509 certificates [was: Re: WKD for GitHub pages]

2021-01-16 Thread Stefan Claas via Gnupg-users
On Sat, Jan 16, 2021 at 12:52 PM Stefan Claas
 wrote:
>
> On Sat, Jan 16, 2021 at 10:32 AM Juergen Bruckner via Gnupg-users
>  wrote:
> >
> > Hello Group!
>
> > BTW ... do any of you know a tutorial to set up WKD for 'Dummies'?
>
> Hi Juergen,
>
> me as a Windows DAU (Dümmster Anzunehmnder User) used the direct-method:

[EDIT]

> Create in your web server's root directory the following:
> a directory '.well-known' and in that
> a folder named 'openpgpkey' put in that folder another folder named: 'hu'.

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: CNAME aliases for wkd.keys.openpgp.org and X.509 certificates [was: Re: WKD for GitHub pages]

2021-01-16 Thread Stefan Claas via Gnupg-users
On Sat, Jan 16, 2021 at 10:32 AM Juergen Bruckner via Gnupg-users
 wrote:
>
> Hello Group!

> BTW ... do any of you know a tutorial to set up WKD for 'Dummies'?

Hi Juergen,

me as a Windows DAU (Dümmster Anzunehmnder User) used the direct-method:

Create in your web server's root directory the following:

a folder named 'openpgpkey' put in that folder another folder named: 'hu'.

in the openpgpkey folder put a policy file, named 'policy' it can be empty.

in the hu folder put the binary blob of your pub key(s)

to create the proper pub key do the following:

gpg --list-keys --with-wkd-hash

it will show you your pub keys data with an additional hash

in order to export your pub key do the following:

gpg --export your_pubkey >hash_as_filename

put that binary blob of your pub key in your hu folder so that the
filename shows the hash,
without the @email part.

then use Wiktor's WKD checker to check your result.

If everything went well you can try to fetch your pub key with

gpg --locate-keys juergen@email.address

Hope this helps and please report back your results.

Best regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: CNAME aliases for wkd.keys.openpgp.org and X.509 certificates [was: Re: WKD for GitHub pages]

2021-01-16 Thread Juergen Bruckner via Gnupg-users

Hello Group!

Am 16.01.21 um 03:26 schrieb Vincent Breitmoser via Gnupg-users:


Daniel Kahn Gillmor via Gnupg-users  wrote:

On Mon 2021-01-11 22:59:10 +0100, Ángel wrote:

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?)


In fact, i believe that keys.openpgp.org *is* requesting and retaining a
certificate on-the-fly if it finds itself addressed by such a CNAME.


Yep. If that wasn't possible, we wouldn't do it.

btw, if anyone is interested: keys.o.o serves wkd for 224 domains right now.

  - V


Now I'm a bit confused :O
I thought WKD can be used with your own webserver. So why do I have to 
make a CNAME recort pointing to "wkd.keys.openpgp.org"?


Or did I understand anything wrong?

BTW ... do any of you know a tutorial to set up WKD for 'Dummies'?

best regards
Juergen


--
/¯\   No  |
\ /  HTML |Juergen Bruckner
 Xin  |juergen@bruckner.email
/ \  Mail |



smime.p7s
Description: S/MIME Cryptographic Signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: CNAME aliases for wkd.keys.openpgp.org and X.509 certificates [was: Re: WKD for GitHub pages]

2021-01-15 Thread Vincent Breitmoser via Gnupg-users

Daniel Kahn Gillmor via Gnupg-users  wrote:
> On Mon 2021-01-11 22:59:10 +0100, Ángel wrote:
> > 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?)
>
> In fact, i believe that keys.openpgp.org *is* requesting and retaining a
> certificate on-the-fly if it finds itself addressed by such a CNAME.

Yep. If that wasn't possible, we wouldn't do it.

btw, if anyone is interested: keys.o.o serves wkd for 224 domains right now.

 - V

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

CNAME aliases for wkd.keys.openpgp.org and X.509 certificates [was: Re: WKD for GitHub pages]

2021-01-15 Thread Daniel Kahn Gillmor via Gnupg-users
On Mon 2021-01-11 22:59:10 +0100, Ángel wrote:
> 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?)

In fact, i believe that keys.openpgp.org *is* requesting and retaining a
certificate on-the-fly if it finds itself addressed by such a CNAME.

--dkg


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD for GitHub pages

2021-01-13 Thread Stefan Claas via Gnupg-users
On Wed, Jan 13, 2021 at 8:42 AM Daniele Nicolodi  wrote:
>
> On 12/01/2021 23:30, Stefan Claas wrote:
> > The reason why I like also the option for, let's say github.io pages
> > is that, like I have shown in the whole thread that a very well known
> > site like GitHub, with it's millions of software developes allows one
> > to host, via WKD, a mutli-purpose usage public-key without revealing
> > to much details.
>
> I still don't understand why you insist on WKD when it seems to do not
> support your use case, nor to offer any advantage over a simpler
>
> wget -O- https://sac001.github.io/foobar.asc | gpg --import
>
> given that the relation between the identifiers
> "ste...@sac001.github.io" or "https://sac001.github.io/foobar.asc"; and
> the key you are retrieving is the same, ie none.

Hi Dan,

Good question, WKD is a valid option to retrieve pub keys with OpenPGP
apps people use and rely on. I could for example also use curl to retrieve
keys from Hagrid or SKS. ;-)

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: WKD for GitHub pages

2021-01-13 Thread Daniele Nicolodi
On 12/01/2021 23:30, Stefan Claas wrote:
> The reason why I like also the option for, let's say github.io pages
> is that, like I have shown in the whole thread that a very well known
> site like GitHub, with it's millions of software developes allows one
> to host, via WKD, a mutli-purpose usage public-key without revealing
> to much details.

I still don't understand why you insist on WKD when it seems to do not
support your use case, nor to offer any advantage over a simpler

wget -O- https://sac001.github.io/foobar.asc | gpg --import

given that the relation between the identifiers
"ste...@sac001.github.io" or "https://sac001.github.io/foobar.asc"; and
the key you are retrieving is the same, ie none.

Cheers,
Dan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: WKD for GitHub pages

2021-01-13 Thread Daniele Nicolodi
On 12/01/2021 22:17, Stefan Claas wrote:
> On Tue, Jan 12, 2021 at 10:09 PM Daniele Nicolodi  wrote:
>>
>> On 12/01/2021 20:40, Stefan Claas via Gnupg-users wrote:
>>> On Tue, Jan 12, 2021 at 8:17 PM André Colomb  wrote:

 Hi Stefan,
>>>
 So there are two "bugs" involved here.  1. GitHub presenting an invalid
 certificate for the sub-subdomain and 2. Sequoia not noticing that.
 Neither of these are bugs in GnuPG.  If you can accept these facts, then
 it makes sense to further discuss what could be changed where to make
 your desired setup work.  Maybe that discussion will lead to a concise
 change proposal.
>>>
>>> Hi Andre, currently I can only accept the fact that these two "bugs" are
>>> currently not resolved in GnuPG and gpg4win, if you allow me to
>>> formulate it this way.
>>
>> How can GPG solve bugs that are not in the GPG code or infrastructure? I
>> think André did a great job explaining what the issues are. How do you
>> think they can be addressed by GPG?
> 
> If you followed the whole thread you may agree that GnuPG and gpg4win,
> due to the way of how WKD is implemented does not allow wildcard (sub)domains,
> when fetching a pub key from, for example, github.io pages, because it gives
> a cert error for a *valid* SSL cert, while other OpenPGP software,
> like sequoia-pgp,
> can handle this.

It has been explained (several times now) that this is not the cases:
the certificates are invalid for sub-subdomains. Why are you insisting
that they are?

Cheers,
Dan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD for GitHub pages

2021-01-12 Thread Stefan Claas via Gnupg-users
On Wed, Jan 13, 2021 at 12:00 AM André Colomb  wrote:
>
> On 12/01/2021 23.47, Stefan Claas wrote:
> > Mmmh ... github.io or GitHub does *not* have issues with wildcard
> > domains ...
>
> Here we are back at you denying facts, or maybe just generalizing too
> much.  As several others have put it already:
>
> When "browsing" to openpgpkey.sac001.github.io with whatever reasonable
> HTTPS client, you are directed to an IP address.  The web server at that
> IP address presents a certificate for (among others) *.github.io.  This
> certificate is *invalid* for the originally entered domain name.  No
> matter how many times you deny it.
>
> For sac001.github.io, the certificate is *valid*.  Nobody ever
> questioned that.  But it doesn't mean the above is untrue.
>
> Stay safe.
> André

Why in the name of (whoever) does one need to browse a URL, with an openpgp
part, If my browser does not allow me (AFAIK) to see it's content in
that openpgp
folder, or why do I/we need that for fetching securely a pub.key, if
the direct method
works (with sequoia-pgp) and Wiktor's WKD checker gives a green light for direct
and IIRC you initally said direct for fetching is fine?

Ok, I must say good night know, because I must get up early today.

Stay safe too!

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD for GitHub pages

2021-01-12 Thread André Colomb
On 12/01/2021 23.47, Stefan Claas wrote:
> Mmmh ... github.io or GitHub does *not* have issues with wildcard
> domains ...

Here we are back at you denying facts, or maybe just generalizing too
much.  As several others have put it already:

When "browsing" to openpgpkey.sac001.github.io with whatever reasonable
HTTPS client, you are directed to an IP address.  The web server at that
IP address presents a certificate for (among others) *.github.io.  This
certificate is *invalid* for the originally entered domain name.  No
matter how many times you deny it.

For sac001.github.io, the certificate is *valid*.  Nobody ever
questioned that.  But it doesn't mean the above is untrue.

Stay safe.
André

-- 
Greetings...
From: André Colomb 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD for GitHub pages

2021-01-12 Thread André Colomb
On 12/01/2021 23.33, Stefan Claas via Gnupg-users wrote:
> On Tue, Jan 12, 2021 at 11:32 PM Remco Rijnders  wrote:
>> I don't see the valid SSL certificate you keep on insisting is there.

I totally agree with that.  It's valid for the sac001 subdomain, but
INVALID for anything below that, which GitHub still happily (and
wrongfully) uses it for when asked though.

> Hi, I suggest that you visit my https://sac001.github.io page and see what
> it is all about. (BTW. I am also not affilated in any form with Brave ...)

Sorry, that didn't enlighten me at all.  So what is it all about?  What
does it have to do with timestamping?

On a side note: Your sac001 account carries your full name, same as used
on this mailing list.  You are probably the only one using WKD in this
context on github.io.  So whatever new account you create, people could
very soon find out who is behind that scheme :-)  So, only anonymous in
theory.

Kind regards
André

-- 
Greetings...
From: André Colomb 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD for GitHub pages

2021-01-12 Thread Stefan Claas via Gnupg-users
On Tue, Jan 12, 2021 at 11:46 PM André Colomb  wrote:
>
> Hi Stefan,
>
> On 12/01/2021 23.16, Stefan Claas wrote:
> > Andre, please appoligze that I snipped your reply and that I only
> > give a short reply, your explanations of server/client IO was
> > welcome.
>
> I'm happy if it helps keeping this discussion constructive and not
> turning into a flame war :-)
>
> > I think I do undertsand the American Way Of Life quite a bit,
> > meaning that U.S. citizens are more open to privacy related
> > things with security software then maybe us old Sauerkrauts,
> > so to speak. Therefore I doubt that an IMHO very cool billion
> > dollar company like GitHub, according to the reply I got
> > from them, would see WKD usage as harm for their service,
> > when used by many people. I could be wrong of course (in
> > the future)
>
> (Me too Sauerkraut...) But you're missing the point.  GitHub has no
> business whatsoever with e-mail.  WKD is all about e-mail and you are
> probably among the first to use it for something unrelated to e-mail.
> So they don't give a Koffer about some e-mail-related protocol except
> for maybe implementing it (hopefully sometime) for their own employees /
> @github.com e-mail account users.

It does not need to have an email business.

> > Even if there would be no github.io pages available I hope
> > that I showed here something interesting for the GnuPG
> > community.
>
> Interesting yes, to the community, yes.  But not to the billion dollar
> company whose offer has nothing to do with e-mail.  Not interesting in
> the sense of "we will invest time and money and risk breaking other
> users' setups by changing something in our infrastructure" because of
> some creative WKD use case.
>
> By the way, there might be other free web hosting providers you could
> use to serve a couple of bytes via HTTPS.  It's very likely that they do
> not have the same issues with wildcard domains and invalid TLS
> certificates as github.io.

Mmmh ... github.io or GitHub does *not* have issues with wildcard
domains ...

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD for GitHub pages

2021-01-12 Thread André Colomb
Hi Stefan,

On 12/01/2021 23.16, Stefan Claas wrote:
> Andre, please appoligze that I snipped your reply and that I only
> give a short reply, your explanations of server/client IO was
> welcome.

I'm happy if it helps keeping this discussion constructive and not
turning into a flame war :-)

> I think I do undertsand the American Way Of Life quite a bit,
> meaning that U.S. citizens are more open to privacy related
> things with security software then maybe us old Sauerkrauts,
> so to speak. Therefore I doubt that an IMHO very cool billion
> dollar company like GitHub, according to the reply I got
> from them, would see WKD usage as harm for their service,
> when used by many people. I could be wrong of course (in
> the future)

(Me too Sauerkraut...) But you're missing the point.  GitHub has no
business whatsoever with e-mail.  WKD is all about e-mail and you are
probably among the first to use it for something unrelated to e-mail.
So they don't give a Koffer about some e-mail-related protocol except
for maybe implementing it (hopefully sometime) for their own employees /
@github.com e-mail account users.

> Even if there would be no github.io pages available I hope
> that I showed here something interesting for the GnuPG
> community.

Interesting yes, to the community, yes.  But not to the billion dollar
company whose offer has nothing to do with e-mail.  Not interesting in
the sense of "we will invest time and money and risk breaking other
users' setups by changing something in our infrastructure" because of
some creative WKD use case.

By the way, there might be other free web hosting providers you could
use to serve a couple of bytes via HTTPS.  It's very likely that they do
not have the same issues with wildcard domains and invalid TLS
certificates as github.io.

Kind regards
André

-- 
Greetings...
From: André Colomb 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD for GitHub pages

2021-01-12 Thread Stefan Claas via Gnupg-users
On Tue, Jan 12, 2021 at 11:32 PM Remco Rijnders  wrote:
>
> On Tue, Jan 12, 2021 at 10:17:13PM +0100, Stefan wrote in
> :
> >> How can GPG solve bugs that are not in the GPG code or infrastructure? I
> >> think André did a great job explaining what the issues are. How do you
> >> think they can be addressed by GPG?
> >
> >If you followed the whole thread you may agree that GnuPG and gpg4win,
> >due to the way of how WKD is implemented does not allow wildcard 
> >(sub)domains,
> >when fetching a pub key from, for example, github.io pages, because it gives
> >a cert error for a *valid* SSL cert, while other OpenPGP software,
> >like sequoia-pgp,
> >can handle this.
> >
> >I suggest that you or any other persons ask this question Werner, the author
> >of GnuPG and IIRC the wkd-draft author or you ask the sequoia
> >team how they implemented WKD, because sq.exe does it's job.
>
> Firefox gives an error on the URL https://openpgpkey.sac001.github.io/ :
>
> Websites prove their identity via certificates. Firefox does not trust this 
> site
> because it uses a certificate that is not valid for 
> openpgpkey.sac001.github.io.
> The certificate is only valid for the following names: www.github.com,
> *.github.com, github.com, *.github.io, github.io, *.githubusercontent.com,
> githubusercontent.com
>
> I don't see the valid SSL certificate you keep on insisting is there.

Hi, I suggest that you visit my https://sac001.github.io page and see what
it is all about. (BTW. I am also not affilated in any form with Brave ...)

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD for GitHub pages

2021-01-12 Thread Stefan Claas via Gnupg-users
On Tue, Jan 12, 2021 at 11:02 PM Daniele Nicolodi  wrote:

> The point of WKD is using the trust of the CA machinery (and the
> assumption that the email infrastructure and web servers serving a
> specific domain are run by the same organization) to securely retrieve
> OpenPGP keys associated to an email address. There keys can then be used
> to communicate with the older of the email address.
>
> The party in the communication are identified by email addresses.
>
> In your scheme there are no email addresses. How is retrieving an
> OpenPGP key from a random .github.io subdomain from obtaining it in any
> other untrusted way? What is the line of trust in the scheme you are
> proposing?

Please let me clarify one thing (and I do not want to play or act like
a teacher, uknown to you or others)

Before PGP was invented by Mr. Zimmermann, public key cryptography
does not needed a Web of Trust, nor a public key which has to bear a
name or an email address! I for example use besides OpenPGP software
also public key crypto software based on Professor Bernstein's NaCl
library, with friends in the United States, Canada and Germany. This
public key is a 256bit key with not a single content of MetaData and
communicating with my friends is authenticated.

Public Key Cryptography does not mean, even If I place my publicty
available key on a site, that the whole world needs to know with whom
I communicate and from which channels. It is IMHO a misunderstanding
people make, new to public key cryptography, while only knowing popular
OpenPGP software. sequoia-pgp, in that respect, honors this old principle
and allows for exampla also users to create a key pair which does not
need a UID ant therefore can act, same as NaClbox the classic way of
public key cryptography.

The reason why I like also the option for, let's say github.io pages
is that, like I have shown in the whole thread that a very well known
site like GitHub, with it's millions of software developes allows one
to host, via WKD, a mutli-purpose usage public-key without revealing
to much details.

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: WKD for GitHub pages

2021-01-12 Thread Remco Rijnders
On Tue, Jan 12, 2021 at 10:17:13PM +0100, Stefan wrote in 
:

How can GPG solve bugs that are not in the GPG code or infrastructure? I
think André did a great job explaining what the issues are. How do you
think they can be addressed by GPG?


If you followed the whole thread you may agree that GnuPG and gpg4win,
due to the way of how WKD is implemented does not allow wildcard (sub)domains,
when fetching a pub key from, for example, github.io pages, because it gives
a cert error for a *valid* SSL cert, while other OpenPGP software,
like sequoia-pgp,
can handle this.

I suggest that you or any other persons ask this question Werner, the author
of GnuPG and IIRC the wkd-draft author or you ask the sequoia
team how they implemented WKD, because sq.exe does it's job.


Firefox gives an error on the URL https://openpgpkey.sac001.github.io/ :

Websites prove their identity via certificates. Firefox does not trust this site
because it uses a certificate that is not valid for openpgpkey.sac001.github.io.
The certificate is only valid for the following names: www.github.com,
*.github.com, github.com, *.github.io, github.io, *.githubusercontent.com,
githubusercontent.com

I don't see the valid SSL certificate you keep on insisting is there.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: WKD for GitHub pages

2021-01-12 Thread Stefan Claas via Gnupg-users
On Tue, Jan 12, 2021 at 10:58 PM André Colomb  wrote:

[...]

Andre, please appoligze that I snipped your reply and that I only
give a short reply, your explanations of server/client IO was
welcome.

In my OP I only asked for help from the community to set-up
WKD for GnuPG or gpg4win usage and I gave also in this
thread a couple of thoughts why WKD could be a very useful
addition to Hagrid and later hockerpuck.

I think I do undertsand the American Way Of Life quite a bit,
meaning that U.S. citizens are more open to privacy related
things with security software then maybe us old Sauerkrauts,
so to speak. Therefore I doubt that an IMHO very cool billion
dollar company like GitHub, according to the reply I got
from them, would see WKD usage as harm for their service,
when used by many people. I could be wrong of course (in
the future)

Even if there would be no github.io pages available I hope
that I showed here something interesting for the GnuPG
community.

Best regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD for GitHub pages

2021-01-12 Thread Daniele Nicolodi
On 12/01/2021 20:40, Stefan Claas via Gnupg-users wrote:
> On Tue, Jan 12, 2021 at 8:17 PM André Colomb  wrote:

>> One more question: You're talking about OpenPGP key discovery setups for
>> families and small groups, IIUC.  And that should involve WKD and
>> GitHub.  But how should these people actually get working e-mail
>> addresses @example.github.io?  WKD very specifically ties the key
>> discovery to the control over the involved domain.  It moves part of the
>> trust relationship to the domain administrator.  So who is actually in
>> control over those e-mail addresses?
> 
> Good question Andre! In case of github.io there is apprently no
> email address, which is IMHO a good thing if people like to
> set-up a github.io page and do not want to reveal their real
> email address, to third parties, which is IMHO their good right,
> in case they like to use this github.io pub key as multi-purpose
> key, let's say for multiple email accounts, from other services,
> file transfer, NFC postcards, you name it.

The point of WKD is using the trust of the CA machinery (and the
assumption that the email infrastructure and web servers serving a
specific domain are run by the same organization) to securely retrieve
OpenPGP keys associated to an email address. There keys can then be used
to communicate with the older of the email address.

The party in the communication are identified by email addresses.

In your scheme there are no email addresses. How is retrieving an
OpenPGP key from a random .github.io subdomain from obtaining it in any
other untrusted way? What is the line of trust in the scheme you are
proposing?

Cheers,
Dan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD for GitHub pages

2021-01-12 Thread André Colomb
On 12/01/2021 20.40, Stefan Claas wrote:
>> So there are two "bugs" involved here.  1. GitHub presenting an invalid
>> certificate for the sub-subdomain and 2. Sequoia not noticing that.
>> Neither of these are bugs in GnuPG.  If you can accept these facts, then
>> it makes sense to further discuss what could be changed where to make
>> your desired setup work.  Maybe that discussion will lead to a concise
>> change proposal.
> 
> Hi Andre, currently I can only accept the fact that these two "bugs" are
> currently not resolved in GnuPG and gpg4win, if you allow me to
> formulate it this way. I desperately hope that this thread will lead to a

I (and others) understand the word "bug" as in "software not working
according to its specification".  The specification is the WKD Internet
Draft as well as some RFCs about TLS certificate rules.  Bugs in Sequoia
or GitHub's DNS configuration can therefore not be resolved in a
different software, namely GnuPG.  Not sure what you mean by "resolve"
otherwise.  Ignoring security rules would be a workaround, and a
terrible one as well.

Regarding the "misconfiguration" of GitHub's DNS and HTTPS, I noticed
Werner has actually added a corresponding paragraph to the WKD draft in
May 2019 (version 08):

   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.

Of course that only applies for someone striving for WKD conformance,
which the github.io domain has absolutely no business with.  Therefore
they don't take this extra measure to suppress a failed attempt with the
WKD advanced method.

> Good question Andre! In case of github.io there is apprently no
> email address, which is IMHO a good thing if people like to
> set-up a github.io page and do not want to reveal their real
> email address, to third parties, which is IMHO their good right,
> in case they like to use this github.io pub key as multi-purpose
> key, let's say for multiple email accounts, from other services,
> file transfer, NFC postcards, you name it.

Okay, so you're using a protocol (WKD) that was purpose-designed with
e-mail in mind, but your user IDs don't work as e-mail addresses.
Despite looking exactly alike.  That in itself might confuse people
(like me) using those keys.  However WKD itself is not strictly tied to
e-mail, in contrast to WKS (the related Web Key Service protocol).

> Let's say as an example for gnupg.org. If am not mistaken
> dev.gnupg.org has a different cert as gnupg.org. Let's assume
> also that gnupg.org would come up with the idea of running
> keys.gnupg.org. I strongly believe that a (purchased) SSL
> cert for gnupg.org, covering wildcard subdomains, like GitHub's
> cert is neither wrong nor does it cause any security implications,
> when the direct method is used.

You need to distinguish at which level the wildcard is found.  A TLS
certificate for *.gnupg.org would be perfectly fine, and even if
dev.gnupg.org uses its own even though it would be covered by the
wildcard.  A fictional openpgpkey.gnupg.org server could present the
wildcard cert, just as GitHub does it.  But for an
openpgpkey.dev.gnupg.org server, that would be invalid.  Again, a
certificate for *.dev.gnupg.org could be used there.

There's two sides to the validity: DNS and TLS.  Going back to the
GitHub example for continuity.  The DNS server resolves
example.github.io to some IP address.  It also resolves any
sub-subdomain like openpgpkey.example.github.io to a (probably the same)
IP address.  The web server at that address presents a TLS certificate
which is issued for *.github.io.  It would need to present a different
certificate for *.example.github.io in order to make a valid TLS
authenticated connection.  I don't think there is something like a
*.*.github.io entry they could include in their certificate that would
cover all sub- and sub-sub-domains at once.  So the HTTPS connection to
openpgpkey.example.github.io "works" on the DNS level, but has NO VALID
TLS set up, which is the "bug" / error on their side.

> Speaking of overhead, I must admit (again) I do not understand
> what this is or what this can cause for a server maintainer or
> a GnuPG or gpg4win user, when I for example can fetch my
> pub key with sequoia real quick, because in binary form these
> are only a couple of bytes and I strongly believe that a simple
> directory structure, holding some files, on a web server has no
> issues either.

I'll try to explain what happens during a WKD lookup attempt in your
preferred order, in hopefully simple terms (not 100 % technically correct).

1. The client queries DNS for the github.io domain, gets back an NS
record (a name server for the github.io zone).
2. Client asks the returned DNS server about example.github.io, gets
back an IP address for the (web) server.
3. Client contacts the web server on port 44

Re: WKD for GitHub pages

2021-01-12 Thread Stefan Claas via Gnupg-users
On Tue, Jan 12, 2021 at 10:09 PM Daniele Nicolodi  wrote:
>
> On 12/01/2021 20:40, Stefan Claas via Gnupg-users wrote:
> > On Tue, Jan 12, 2021 at 8:17 PM André Colomb  wrote:
> >>
> >> Hi Stefan,
> >
> >> So there are two "bugs" involved here.  1. GitHub presenting an invalid
> >> certificate for the sub-subdomain and 2. Sequoia not noticing that.
> >> Neither of these are bugs in GnuPG.  If you can accept these facts, then
> >> it makes sense to further discuss what could be changed where to make
> >> your desired setup work.  Maybe that discussion will lead to a concise
> >> change proposal.
> >
> > Hi Andre, currently I can only accept the fact that these two "bugs" are
> > currently not resolved in GnuPG and gpg4win, if you allow me to
> > formulate it this way.
>
> How can GPG solve bugs that are not in the GPG code or infrastructure? I
> think André did a great job explaining what the issues are. How do you
> think they can be addressed by GPG?

If you followed the whole thread you may agree that GnuPG and gpg4win,
due to the way of how WKD is implemented does not allow wildcard (sub)domains,
when fetching a pub key from, for example, github.io pages, because it gives
a cert error for a *valid* SSL cert, while other OpenPGP software,
like sequoia-pgp,
can handle this.

I suggest that you or any other persons ask this question Werner, the author
of GnuPG and IIRC the wkd-draft author or you ask the sequoia
team how they implemented WKD, because sq.exe does it's job.

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD for GitHub pages

2021-01-12 Thread Daniele Nicolodi
On 12/01/2021 20:40, Stefan Claas via Gnupg-users wrote:
> On Tue, Jan 12, 2021 at 8:17 PM André Colomb  wrote:
>>
>> Hi Stefan,
> 
>> So there are two "bugs" involved here.  1. GitHub presenting an invalid
>> certificate for the sub-subdomain and 2. Sequoia not noticing that.
>> Neither of these are bugs in GnuPG.  If you can accept these facts, then
>> it makes sense to further discuss what could be changed where to make
>> your desired setup work.  Maybe that discussion will lead to a concise
>> change proposal.
> 
> Hi Andre, currently I can only accept the fact that these two "bugs" are
> currently not resolved in GnuPG and gpg4win, if you allow me to
> formulate it this way.

How can GPG solve bugs that are not in the GPG code or infrastructure? I
think André did a great job explaining what the issues are. How do you
think they can be addressed by GPG?

Cheers,
Dan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD for GitHub pages

2021-01-12 Thread Stefan Claas via Gnupg-users
On Tue, Jan 12, 2021 at 9:43 PM Andrew Gallagher  wrote:
>
>
> > On 12 Jan 2021, at 19:44, Stefan Claas via Gnupg-users 
> >  wrote:
> >
> > Hi Andre, currently I can only accept the fact that these two "bugs" are
> > currently not resolved in GnuPG and gpg4win, if you allow me to
> > formulate it this way.
>
> You should not formulate it this way. If the bugs are not in gnupg, they 
> cannot be resolved in gnupg.

Ok, than I should formulate it as feature request, for GnuPG and gpg4win.

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: WKD for GitHub pages

2021-01-12 Thread Andrew Gallagher


> On 12 Jan 2021, at 19:44, Stefan Claas via Gnupg-users 
>  wrote:
> 
> Hi Andre, currently I can only accept the fact that these two "bugs" are
> currently not resolved in GnuPG and gpg4win, if you allow me to
> formulate it this way.

You should not formulate it this way. If the bugs are not in gnupg, they cannot 
be resolved in gnupg.

A
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: WKD for GitHub pages

2021-01-12 Thread Stefan Claas via Gnupg-users
On Tue, Jan 12, 2021 at 8:17 PM André Colomb  wrote:
>
> Hi Stefan,

> So there are two "bugs" involved here.  1. GitHub presenting an invalid
> certificate for the sub-subdomain and 2. Sequoia not noticing that.
> Neither of these are bugs in GnuPG.  If you can accept these facts, then
> it makes sense to further discuss what could be changed where to make
> your desired setup work.  Maybe that discussion will lead to a concise
> change proposal.

Hi Andre, currently I can only accept the fact that these two "bugs" are
currently not resolved in GnuPG and gpg4win, if you allow me to
formulate it this way. I desperately hope that this thread will lead to a
fruitful outcome, for GnuPG and gpg4win users, while I personally
could care less, because I just checked yesterday the latest sq
version and I am happy that it works.

> One more question: You're talking about OpenPGP key discovery setups for
> families and small groups, IIUC.  And that should involve WKD and
> GitHub.  But how should these people actually get working e-mail
> addresses @example.github.io?  WKD very specifically ties the key
> discovery to the control over the involved domain.  It moves part of the
> trust relationship to the domain administrator.  So who is actually in
> control over those e-mail addresses?

Good question Andre! In case of github.io there is apprently no
email address, which is IMHO a good thing if people like to
set-up a github.io page and do not want to reveal their real
email address, to third parties, which is IMHO their good right,
in case they like to use this github.io pub key as multi-purpose
key, let's say for multiple email accounts, from other services,
file transfer, NFC postcards, you name it.

Let's say as an example for gnupg.org. If am not mistaken
dev.gnupg.org has a different cert as gnupg.org. Let's assume
also that gnupg.org would come up with the idea of running
keys.gnupg.org. I strongly believe that a (purchased) SSL
cert for gnupg.org, covering wildcard subdomains, like GitHub's
cert is neither wrong nor does it cause any security implications,
when the direct method is used.

Speaking of overhead, I must admit (again) I do not understand
what this is or what this can cause for a server maintainer or
a GnuPG or gpg4win user, when I for example can fetch my
pub key with sequoia real quick, because in binary form these
are only a couple of bytes and I strongly believe that a simple
directory structure, holding some files, on a web server has no
issues either.

> I hope this mail will not upset you.  Just trying to clarify what you
> might have misunderstood that leads to people not understanding or
> agreeing with your proposal.  I don't mind to be proven wrong if it was
> in fact my misunderstanding.

Of course not and I appreciate if this issue can be discussed further!

Best regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD for GitHub pages

2021-01-12 Thread André Colomb
Hi Stefan,

maybe I'm not the only one here who doesn't fully follow what your
"proposal" actually is.  For me, it sounds like you are misunderstanding
some things and therefore think you are making a superior proposal where
it is actually based on wrong assumptions.

On 12/01/2021 18.05, Stefan Claas via Gnupg-users wrote:
> please ... openpgpkey is *not* a part of a real (sub)domain, which a
> user of any domain service has to define in a record.

I do not understand this statement at all.  Could you please elaborate?

> Please accept also that a modern OpenPGP software like sequoia-pgp
> can handle this *adequately* with the direct method first!

It seems adequate for *you*, but as I explained it would put a burden on
both the client and the involved webservers to handle it that way.  In
case the advanced method is available, and the direct method is not,
testing for the direct method first is not a cheap operation.

It has also been pointed out repeatedly in this thread that Sequoia
apparently does not properly check the TLS certificate, which you have
proven with your example setup.  That could be called "modern" or
"insecure".  It has nothing to do with the ordering of the two methods.

> Additionally I have received from GitHub a very nice reply, which I and
> I guess all will accept here!
> 
> Quote: "... however I don't believe GitHub is in a position to try and 
> persuade
> a software author to change or fix their software."

I agree they shouldn't try that.  Your question to them probably hinted
at something being the problem which is not in their control.  While
actually the real problem is something else which they could control on
their side (see below).

> At least the global OpenPGP community is now aware of my proposal
> and I repeat here once again: GitHub (which I am not affiliated with in
> any form) has a *proper* SSL cert and github.io pages are properly
> working subdomain sites, wiich GnuPG's and gpg4win's WKD implementation

This is plain wrong, as Ingo has pointed out.  But let me explain to you
why I think so.

The certificate is issued for *.github.io.  So it is valid for anything
like example.github.io, openpgpkey.github.io, whatever.github.io.  But
it is NOT VALID for any deeper level of subdomain, like
foo.bar.github.io or openpgpkey.example.github.io.  That's just how TLS
certificate validity is defined.

However, GitHub apparently still presents that certificate when making
an HTTPS connection to the deeper subdomains, e.g.
openpgpkey.example.github.io.  For this connection, the certificate is
definitely NOT VALID, as curl or gnupg do point out.  Sequoia seems to
apply different rules for the hostname check, so it seems to "just work"
for you.  In fact, it should only accept a certificate for
openpgpkey.example.github.io or *.example.github.io.

So there are two "bugs" involved here.  1. GitHub presenting an invalid
certificate for the sub-subdomain and 2. Sequoia not noticing that.
Neither of these are bugs in GnuPG.  If you can accept these facts, then
it makes sense to further discuss what could be changed where to make
your desired setup work.  Maybe that discussion will lead to a concise
change proposal.

One more question: You're talking about OpenPGP key discovery setups for
families and small groups, IIUC.  And that should involve WKD and
GitHub.  But how should these people actually get working e-mail
addresses @example.github.io?  WKD very specifically ties the key
discovery to the control over the involved domain.  It moves part of the
trust relationship to the domain administrator.  So who is actually in
control over those e-mail addresses?

I hope this mail will not upset you.  Just trying to clarify what you
might have misunderstood that leads to people not understanding or
agreeing with your proposal.  I don't mind to be proven wrong if it was
in fact my misunderstanding.

Kind regards
André

-- 
Greetings...
From: André Colomb 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD for GitHub pages

2021-01-12 Thread Stefan Claas via Gnupg-users
On Tue, Jan 12, 2021 at 5:36 PM Ingo Klöcker  wrote:
>
> On Dienstag, 12. Januar 2021 12:47:59 CET Stefan Claas via Gnupg-users wrote:
> > On Tue, Jan 12, 2021 at 12:43 PM Andrew Gallagher 
> wrote:
> > > Yes, WKD is great. But as André has explained, there is an overhead cost
> > > (to everyone) for trying the direct method first, so inverting this to
> > > work around the side effects of an experiment that's tied to one
> > > particular vendor's service is a *huge* ask.
> >
> > Well, I am not sure about the details for a server or a user when it comes
> > to overhead and if you mean with one particular vendow GitHub, well
> > that may be the beginning, for such request. But like I mentioned if people
> > would wish to manage key distribution themselves, without using third
> > parties, like Hagrid or hokeypuck or even running such software and
> > servers I strongly believe that WKD could be an excellent choice, if
> > this would be fixed.
>
> Why do you think anything needs to be changed in gpg? The problem isn't the
> implementation of WKD in gpg. The problem is that GitHub serves sub-sub-
> subdomains like openpgpkey.sac001.github.io with an invalid TLS certificate.
>
> It's not only gpg that complains.
>
> ===
> $ curl https://openpgpkey.sac001.github.io
> curl: (60) SSL: no alternative certificate subject name matches target host
> name 'openpgpkey.sac001.github.io'
> More details here: https://curl.se/docs/sslcerts.html
>
> curl failed to verify the legitimacy of the server and therefore could not
> establish a secure connection to it. To learn more about this situation and
> how to fix it, please visit the web page mentioned above.
> ===
>
> It's easy for people to manage key distribution themselves with WKD. All they
> have to do is setup WKD with or without openpgpkey subdomain with valid (!!!)
> TLS certificates.

Hello Ingo,

please ... openpgpkey is *not* a part of a real (sub)domain, which a
user of any domain service has to define in a record.

Please accept also that a modern OpenPGP software like sequoia-pgp
can handle this *adequately* with the direct method first!

Additionally I have received from GitHub a very nice reply, which I and
I guess all will accept here!

Quote: "... however I don't believe GitHub is in a position to try and persuade
a software author to change or fix their software."

So the last thing besides here discussing the issue with the community is
to file a bug report at: https://dev.gnupg.org/

At least the global OpenPGP community is now aware of my proposal
and I repeat here once again: GitHub (which I am not affiliated with in
any form) has a *proper* SSL cert and github.io pages are properly
working subdomain sites, wiich GnuPG's and gpg4win's WKD implementation
can not handle, while modern OpenPGP implementations like
sequoia-pgp can handle this. BTW. I am also not affiliated in any form with
sequoia or the pep foundation etc.

Best regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD for GitHub pages

2021-01-12 Thread Ingo Klöcker
On Dienstag, 12. Januar 2021 12:47:59 CET Stefan Claas via Gnupg-users wrote:
> On Tue, Jan 12, 2021 at 12:43 PM Andrew Gallagher  
wrote:
> > Yes, WKD is great. But as André has explained, there is an overhead cost
> > (to everyone) for trying the direct method first, so inverting this to
> > work around the side effects of an experiment that's tied to one
> > particular vendor's service is a *huge* ask.
> 
> Well, I am not sure about the details for a server or a user when it comes
> to overhead and if you mean with one particular vendow GitHub, well
> that may be the beginning, for such request. But like I mentioned if people
> would wish to manage key distribution themselves, without using third
> parties, like Hagrid or hokeypuck or even running such software and
> servers I strongly believe that WKD could be an excellent choice, if
> this would be fixed.

Why do you think anything needs to be changed in gpg? The problem isn't the 
implementation of WKD in gpg. The problem is that GitHub serves sub-sub-
subdomains like openpgpkey.sac001.github.io with an invalid TLS certificate.

It's not only gpg that complains.

===
$ curl https://openpgpkey.sac001.github.io
curl: (60) SSL: no alternative certificate subject name matches target host 
name 'openpgpkey.sac001.github.io'
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
===

It's easy for people to manage key distribution themselves with WKD. All they 
have to do is setup WKD with or without openpgpkey subdomain with valid (!!!) 
TLS certificates.

Regards,
Ingo


signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD for GitHub pages

2021-01-12 Thread Stefan Claas via Gnupg-users
On Tue, Jan 12, 2021 at 1:04 PM Stefan Claas
 wrote:
>
> On Tue, Jan 12, 2021 at 12:47 PM Stefan Claas
>  wrote:

> And for the fun factor I could put also an .ots file from my pub key into
> the hu directory,thus making Mallory a bit angry ... :-D

Unfortunaly I am no skilled Golang programmer, otherwise I would write
a WKD key fetch utility, which works like sequoia-pgp, e.g fechting the
binary key blob and displaying the results to stdout and additionally
fetching the younamit.ots file and the policy file, while storing those
in the current workin directory and where the policy file would contain
the fingerprint of my key.

Thus an OpenPGP users could use the direct method, like sequoia-pgp
does, had my pub key and the policy file and .oth file which he can use with
time stamping services.

And it would not break WKD specs.

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: WKD for GitHub pages

2021-01-12 Thread Stefan Claas via Gnupg-users
On Tue, Jan 12, 2021 at 2:22 PM Stefan Claas
 wrote:
>
> On Tue, Jan 12, 2021 at 1:04 PM Stefan Claas
>  wrote:
> >
> > On Tue, Jan 12, 2021 at 12:47 PM Stefan Claas
> >  wrote:
>
> > And for the fun factor I could put also an .ots file from my pub key into
> > the hu directory,thus making Mallory a bit angry ... :-D
>
> Unfortunaly I am no skilled Golang programmer, otherwise I would write
> a WKD key fetch utility, which works like sequoia-pgp, e.g fechting the
> binary key blob and displaying the results to stdout and additionally
> fetching the younamit.ots file and the policy file, while storing those
> in the current workin directory and where the policy file would contain
> the fingerprint of my key.
>
> Thus an OpenPGP users could use the direct method, like sequoia-pgp
> does, had my pub key and the policy file and .oth file which he can use with
> time stamping services.
>
> And it would not break WKD specs.

Edit: the policy file would be timestamped, because it can be pasted
as ASCII file into timestamping web services and would then fulfill a job,
whic I have not yet seen otherwise.

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: WKD for GitHub pages

2021-01-12 Thread Stefan Claas via Gnupg-users
On Tue, Jan 12, 2021 at 12:47 PM Stefan Claas
 wrote:

> Well, I am not sure about the details for a server or a user when it comes
> to overhead and if you mean with one particular vendow GitHub, well
> that may be the beginning, for such request. But like I mentioned if people
> would wish to manage key distribution themselves, without using third
> parties, like Hagrid or hokeypuck or even running such software and
> servers I strongly believe that WKD could be an excellent choice, if
> this would be fixed.

And for the fun factor I could put also an .ots file from my pub key into
the hu directory,thus making Mallory a bit angry ... :-D

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: WKD for GitHub pages

2021-01-12 Thread Stefan Claas via Gnupg-users
On Tue, Jan 12, 2021 at 12:43 PM Andrew Gallagher  wrote:
>
> On 12/01/2021 11:27, Stefan Claas wrote:
> > The point for me is WKD exists and can be used as an cheap inhouse
> > solution, for families or organizations, if it would allow cost effective
> > wildcard subdomain support for SSL certs, which IMHO can not hurt
> > and if the direct method would be triggered first.
>
> Yes, WKD is great. But as André has explained, there is an overhead cost
> (to everyone) for trying the direct method first, so inverting this to
> work around the side effects of an experiment that's tied to one
> particular vendor's service is a *huge* ask.

Well, I am not sure about the details for a server or a user when it comes
to overhead and if you mean with one particular vendow GitHub, well
that may be the beginning, for such request. But like I mentioned if people
would wish to manage key distribution themselves, without using third
parties, like Hagrid or hokeypuck or even running such software and
servers I strongly believe that WKD could be an excellent choice, if
this would be fixed.

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD for GitHub pages

2021-01-12 Thread Andrew Gallagher

On 12/01/2021 11:27, Stefan Claas wrote:

The point for me is WKD exists and can be used as an cheap inhouse
solution, for families or organizations, if it would allow cost effective
wildcard subdomain support for SSL certs, which IMHO can not hurt
and if the direct method would be triggered first.


Yes, WKD is great. But as André has explained, there is an overhead cost 
(to everyone) for trying the direct method first, so inverting this to 
work around the side effects of an experiment that's tied to one 
particular vendor's service is a *huge* ask.


--
Andrew Gallagher

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD for GitHub pages

2021-01-12 Thread Stefan Claas via Gnupg-users
On Tue, Jan 12, 2021 at 11:49 AM Andrew Gallagher  wrote:
>
> On 12/01/2021 08:25, Stefan Claas via Gnupg-users wrote:
>
> > 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.
>
> WKD is used to publish your own keys, or keys belonging to users in your
> own domain. A keyserver is for publishing arbitrary other people's keys.
> It has never been necessary for a business to run its own keyserver in
> order to use PGP.

Let me say first thank you to Damien and Andre, because I want to make it
short and therefore sorry for not replying to your messages.

Your are right, but we all know what happened to the SKS Network and
we know also that Hagrid is perfectly fine for privacy and once a hockeypuck
Network is in operation users will appreciate it too.

The point for me is WKD exists and can be used as an cheap inhouse
solution, for families or organizations, if it would allow cost effective
wildcard subdomain support for SSL certs, which IMHO can not hurt
and if the direct method would be triggered first.

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: WKD for GitHub pages

2021-01-12 Thread Andrew Gallagher

On 12/01/2021 08:25, Stefan Claas via Gnupg-users wrote:


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.


WKD is used to publish your own keys, or keys belonging to users in your 
own domain. A keyserver is for publishing arbitrary other people's keys. 
It has never been necessary for a business to run its own keyserver in 
order to use PGP.


--
Andrew Gallagher



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD for GitHub pages

2021-01-12 Thread Damien Goutte-Gattat via Gnupg-users
On Tue, Jan 12, 2021 at 09:25:15AM +0100, Stefan Claas via Gnupg-users 
wrote:

It would be nice to know why the advanced method was added.


To give more flexibility for people setting up a WKD for more than one 
domain.


Let’s say that I manage example.org and example.net, and I want to serve 
keys for addresses in both domains. With the “direct” method, I need to 
set up two distinct WKD servers, one for each domain. With the 
“advanced” method, I can set up a single server and make 
openpgpkey.example.org and openpgpkey.example.net point to that single 
server.


(SRV records would be the modern and proper way to provide such a level 
of indirection, instead of a subdomain. And indeed, previous versions of 
the WKD draft relied on SRV records. Unfortunately, resolving SRV 
records was problematic for some implementers using some limited 
languages with limited DNS capabilities, so they were scrapped in favor 
of the subdomain approach.)




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.


If you have only one domain to manage and don’t need the indirection 
provided by the advanced method, the direct method is still perfectly 
fine, why replace it?



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 don’t know, it feels more logical to me to look for an indirection 
*first*, and only if there’s no indirection you then look at the target 
domain itself.



- Damien


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD for GitHub pages

2021-01-12 Thread André Colomb
On 12/01/2021 09.25, Stefan Claas via Gnupg-users wrote:
> 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.

A domain is not automatically tied to a webserver.  It might so far only
be used for e-mail and just to set up WKD, one might not want to run a
webserver under the second-level domain itself.  Therefore the
standardized "openpgpkey" subdomain, which can easily point to a
different IP.  That makes it easy to completely separate the
infrastructure needed for WKD from anything else, like a webserver for a
web page, webmail or other services.

In addition, that separate server might serve WKD keys for a bunch of
different domains through redirects, hence it makes sense to separate
the URLs per domain.  It just gives the admin additional flexibility by
not forcing them to make a certain URL under the main domain work.

> 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.

That's easy: If openpgpkey.example.org exists, we can be certain that
example.org exists as well.  So the check for the openpgpkey subdomain
must come first if its mere existence decides which method is tried.
Otherwise you would get HTTPS connections for every WKD request on the
example.org server, which fail if the direct method is not supported.
Just to make another HTTPS connection to openpgpkey.example.org to try
the advanced method next.  That's a lot of overhead on both the client
and server side, compared to the two DNS queries you need to make either
way.

Hope that helps.
André

-- 
Greetings...
From: André Colomb 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD for GitHub pages

2021-01-12 Thread Stefan Claas via Gnupg-users
On Mon, Jan 11, 2021 at 11:03 PM Ángel  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 w...@gnupg.org Using --with-wkd-hash parameter, we can see that
> > > this
> > > would generate nq6t9teux7edsnwdksswydu4o9i5e...@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

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD for GitHub pages

2021-01-11 Thread Ángel
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 w...@gnupg.org Using --with-wkd-hash parameter, we can see that
> > this
> > would generate nq6t9teux7edsnwdksswydu4o9i5e...@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.


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)


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'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.

Best regards


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: WKD for GitHub pages

2021-01-11 Thread Stefan Claas via Gnupg-users
On Mon, Jan 11, 2021 at 6:16 PM Andrew Gallagher  wrote:
>
> On 11/01/2021 16:32, Stefan Claas via Gnupg-users wrote:
> > I will do this in the next couple of days, in case Werner does not
> > chime in (assuming
> > he is not 'AWOL').
>
> Stefan, please dial down the casual sniping at Werner. It's not
> constructive.

Ok, Andrew I hereby apologize to Werner!

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: WKD for GitHub pages

2021-01-11 Thread Andrew Gallagher

On 11/01/2021 16:32, Stefan Claas via Gnupg-users wrote:

I will do this in the next couple of days, in case Werner does not
chime in (assuming
he is not 'AWOL').


Stefan, please dial down the casual sniping at Werner. It's not 
constructive.


--
Andrew Gallagher



OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD for GitHub pages

2021-01-11 Thread Stefan Claas via Gnupg-users
On Mon, Jan 11, 2021 at 4:55 PM ಚಿರಾಗ್ ನಟರಾಜ್ via Gnupg-users
 wrote:
>
> 12021/00/10 04:42.21 ನಲ್ಲಿ, Stefan Claas via Gnupg-users 
>  ಬರೆದರು:
> > Not sure if Let's Encrypt issues such certs. If, I could set-up two 
> > droplets at
> > Digital Ocean, a bob.300baud.de one and an alice.300baud.de one and see
> > what happens.
>
> Let's Encrypt does offer such certificates. You can generate using e.g.:
>
> sudo certbot certonly --rsa-key-size 4096 --manual -d *.domain.tld
>
> (editing parameters as necessary).
>
> HTH!

Great, thanks for the info!

I will do this in the next couple of days, in case Werner does not
chime in (assuming
he is not 'AWOL').

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD for GitHub pages

2021-01-11 Thread ಚಿರಾಗ್ ನಟರಾಜ್ via Gnupg-users
12021/00/10 04:42.21 ನಲ್ಲಿ, Stefan Claas via Gnupg-users 
 ಬರೆದರು:
> Not sure if Let's Encrypt issues such certs. If, I could set-up two droplets 
> at
> Digital Ocean, a bob.300baud.de one and an alice.300baud.de one and see
> what happens.

Let's Encrypt does offer such certificates. You can generate using e.g.:

sudo certbot certonly --rsa-key-size 4096 --manual -d *.domain.tld

(editing parameters as necessary).

HTH!

- Chiraag
-- 
ಚಿರಾಗ್ ನಟರಾಜ್
Pronouns: he/him/his


publickey - mailinglist@chiraag.me - b0c8d720.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD for GitHub pages

2021-01-11 Thread Stefan Claas via Gnupg-users
On Sun, Jan 10, 2021 at 11:22 PM Ángel  wrote:
>
> On 2021-01-10 at 18:47 +0100, Stefan Claas via Gnupg-users wrote:
> > Can you tell me/us in laymen terms how this works with gnupg.org?
> >
> > openpgpkey.gnupg.org has address 217.69.77.222
> > openpgpkey.gnupg.org has IPv6 address 2001:aa8:fff1:100::22
> >
> > Regards
> > Stefan
>
> Sure. Let's suppose you wanted to fetch Werner's key. You want the key
> for w...@gnupg.org Using --with-wkd-hash parameter, we can see that this
> would generate nq6t9teux7edsnwdksswydu4o9i5e...@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.

Not sure if Let's Encrypt issues such certs. If, I could set-up two droplets at
Digital Ocean, a bob.300baud.de one and an alice.300baud.de one and see
what happens.

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD for GitHub pages

2021-01-10 Thread Ángel
On 2021-01-10 at 18:47 +0100, Stefan Claas via Gnupg-users wrote:
> Can you tell me/us in laymen terms how this works with gnupg.org?
> 
> openpgpkey.gnupg.org has address 217.69.77.222
> openpgpkey.gnupg.org has IPv6 address 2001:aa8:fff1:100::22
> 
> Regards
> Stefan

Sure. Let's suppose you wanted to fetch Werner's key. You want the key
for w...@gnupg.org Using --with-wkd-hash parameter, we can see that this
would generate nq6t9teux7edsnwdksswydu4o9i5e...@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



Best regards




___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: WKD for GitHub pages

2021-01-10 Thread Stefan Claas via Gnupg-users
On Sun, Jan 10, 2021 at 6:01 PM Ángel  wrote:

> sequoia is in the wrong here. You don't have a valid SSL cert for
> openpgpkey.sac001.github.io Either they are not supporting the advanced
> method (maybe they follow an older draft?) or they ignore the
> certificate failure (which would be quite bad).
>
>
>
> The issue here is why github is publishing subdomains that nobody can
> use, anyway. This would usually be harder (why create a openpgp
> subdomain if you don't want it?), but GitHub configuration is already
> sufficiently advanced that it breaks this (it was simpler for them to
> configure their nameservers to also return that for subdomains?).

Can you tell me/us in laymen terms how this works with gnupg.org?

openpgpkey.gnupg.org has address 217.69.77.222
openpgpkey.gnupg.org has IPv6 address 2001:aa8:fff1:100::22

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD for GitHub pages

2021-01-10 Thread Ángel
On 2021-01-09 at 23:40 +0100, Stefan Claas via Gnupg-users wrote:
> 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.

The way it is defined, it makes complete sense. The advanced method
allows a finer control. For example, you could have your web page in
one hosting (such as a CDN you may not trust too much) and your pgp
keys in a different host that you could consider more trustworthy.

The terms easy and advanced refers to the difficulty of setting it up.
Normally, creating a subdomain would be more complex (you need to
create a second dns record, perhaps also create a new VirtualHost…). It
is more powerful, but it's less accessible.

You need to check the first, since the bare domain is pretty much
guaranteed to exist, even without relation to openpgp keys. Plus, with
the above, your lack of trust could be e.g. that you don't want them 
-for privacy reasons- to know which keys are being fetched. Using a
separated host that is tried first solves it. 



> 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.

sequoia is in the wrong here. You don't have a valid SSL cert for
openpgpkey.sac001.github.io Either they are not supporting the advanced
method (maybe they follow an older draft?) or they ignore the
certificate failure (which would be quite bad).



The issue here is why github is publishing subdomains that nobody can
use, anyway. This would usually be harder (why create a openpgp
subdomain if you don't want it?), but GitHub configuration is already
sufficiently advanced that it breaks this (it was simpler for them to
configure their nameservers to also return that for subdomains?).

Regards


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD for GitHub pages

2021-01-09 Thread Stefan Claas via Gnupg-users
On Sat, Jan 9, 2021 at 11:49 PM Stefan Claas
 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
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: WKD for GitHub pages

2021-01-09 Thread Stefan Claas via Gnupg-users
On Sat, Jan 9, 2021 at 11:42 PM Ángel  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
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD for GitHub pages

2021-01-09 Thread Stefan Claas via Gnupg-users
On Sat, Jan 9, 2021 at 11:09 PM Ingo Klöcker  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
> >  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
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD for GitHub pages

2021-01-09 Thread Á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
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: WKD for GitHub pages

2021-01-09 Thread 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
>  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


signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD for GitHub pages

2021-01-09 Thread Stefan Claas via Gnupg-users
On Sat, Jan 9, 2021 at 8:08 PM Stefan Claas
 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
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: WKD for GitHub pages

2021-01-09 Thread Stefan Claas via Gnupg-users
On Sat, Jan 9, 2021 at 7:27 PM Ingo Klöcker  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
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD for GitHub pages

2021-01-09 Thread 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
>  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
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: WKD for GitHub pages

2021-01-09 Thread Stefan Claas via Gnupg-users
On Fri, Jan 8, 2021 at 11:34 PM Stefan Claas
 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 ste...@sac001.github.io
> -BEGIN PGP PUBLIC KEY BLOCK-
> Comment: 3731 D9F8 1352 A24D F7E5  F33A 0885 70FC E611 8FD8
> Comment: Stefan Claas 
>
> 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 al...@sac001.github.io
-BEGIN PGP PUBLIC KEY BLOCK-
Comment: 7AD4 F939 3D41 7BBB A46C  FA67 A6DE D562 6D79 841A
Comment: Alice Demo 

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 b...@sac001.github.io
-BEGIN PGP PUBLIC KEY BLOCK-
Comment: 9CF4 2351 254D 5D71 4460  05A9 39E0 8A8E 266D 3C87
Comment: Bob Demo 

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
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: WKD for GitHub pages

2021-01-09 Thread Stefan Claas via Gnupg-users
On Sat, Jan 9, 2021 at 2:37 PM Stefan Claas
 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
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: WKD for GitHub pages

2021-01-09 Thread Stefan Claas via Gnupg-users
On Sat, Jan 9, 2021 at 11:37 AM Neal H. Walfield  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
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: WKD for GitHub pages

2021-01-09 Thread 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
>  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_0x0254 -> WKD_GET -- ste...@sac001.github.io
> gpg: DBG: chan_0x0254 <- S SOURCE https://openpgpkey.sac001.github.io
> gpg: DBG: chan_0x0254 <- 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_0x0254 <- ERR 285212985 Falscher Name 

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
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: WKD for GitHub pages

2021-01-08 Thread Stefan Claas via Gnupg-users
On Fri, Jan 8, 2021 at 11:27 PM André Colomb  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 ste...@sac001.github.io
-BEGIN PGP PUBLIC KEY BLOCK-
Comment: 3731 D9F8 1352 A24D F7E5  F33A 0885 70FC E611 8FD8
Comment: Stefan Claas 

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
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD for GitHub pages

2021-01-08 Thread 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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD for GitHub pages

2021-01-08 Thread Stefan Claas via Gnupg-users
On Fri, Jan 8, 2021 at 10:21 PM Stefan Claas
 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 ste...@sac001.github.io
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: 'ste...@sac001.github.io'
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_0x0254 <- # Home: C:/Users/Nutzer/AppData/Roaming/gnupg
gpg: DBG: chan_0x0254 <- # Config:
C:/Users/Nutzer/AppData/Roaming/gnupg/dirmngr.conf
gpg: DBG: chan_0x0254 <- OK Dirmngr 2.2.25 at your service
gpg: DBG: connection to the dirmngr established
gpg: DBG: chan_0x0254 -> GETINFO version
gpg: DBG: chan_0x0254 <- D 2.2.25
gpg: DBG: chan_0x0254 <- OK
gpg: DBG: chan_0x0254 -> KEYSERVER --clear hkps://keyserver.ubuntu.com
gpg: DBG: chan_0x0254 <- OK
gpg: DBG: chan_0x0254 -> KEYSERVER
gpg: DBG: chan_0x0254 <- S KEYSERVER hkps://keyserver.ubuntu.com
gpg: DBG: chan_0x0254 <- OK
gpg: DBG: chan_0x0254 -> KEYSERVER --clear hkps://keyserver.ubuntu.com
gpg: DBG: chan_0x0254 <- OK
gpg: DBG: chan_0x0254 -> KS_GET -- =ste...@sac001.github.io
gpg: DBG: chan_0x0254 <- S PROGRESS tick ? 0 0
gpg: DBG: chan_0x0254 <- S SOURCE https://162.213.33.8:443
gpg: DBG: chan_0x0254 <- ERR 167772218 Keine Daten 
gpg: Fehler beim automatischen holen von `ste...@sac001.github.io'
über `keyserver': Keine Daten
gpg: DBG: chan_0x0254 -> KEYSERVER --clear hkps://keyserver.ubuntu.com
gpg: DBG: chan_0x0254 <- OK
gpg: DBG: chan_0x0254 -> DNS_CERT --dane ste...@sac001.github.io
gpg: DBG: chan_0x0254 <- ERR 167772187 Nicht gefunden 
gpg: Fehler beim automatischen holen von `ste...@sac001.github.io'
über `DANE': Nicht gefunden
gpg: DBG: chan_0x0254 -> DNS_CERT * stefan.sac001.github.io
gpg: DBG: chan_0x0254 <- ERR 167772187 Nicht gefunden 
gpg: Fehler beim automatischen holen von `ste...@sac001.github.io'
über `DNS CERT': Nicht gefunden
gpg: DBG: chan_0x0254 -> DNS_CERT --pka -- ste...@sac001.github.io
gpg: DBG: chan_0x0254 <- ERR 167772187 Nicht gefunden 
gpg: Fehler beim automatischen holen von `ste...@sac001.github.io'
über `PKA': Nicht gefunden
gpg: DBG: chan_0x0254 -> WKD_GET -- ste...@sac001.github.io
gpg: DBG: chan_0x0254 <- S SOURCE https://openpgpkey.sac001.github.io
gpg: DBG: chan_0x0254 <- 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_0x0254 <- ERR 285212985 Falscher Name 
gpg: Fehler beim automatischen holen von `ste...@sac001.github.io'
über `WKD': Falscher Name
gpg: Fehler beim automatischen holen von `ste...@sac001.github.io'
über `LDAP': Nich implementiert
gpg: error reading key: Nich implementiert
gpg: DBG: chan_0x0254 -> 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=0x calls=0 bytes=0
gpg: secmem usage: 0/32768 bytes in 0 blocks

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD for GitHub pages

2021-01-08 Thread Stefan Claas via Gnupg-users
On Fri, Jan 8, 2021 at 10:07 PM André Colomb  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
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD for GitHub pages

2021-01-08 Thread 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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: WKD for GitHub pages

2021-01-08 Thread Stefan Claas via Gnupg-users
On Fri, Jan 8, 2021 at 7:36 PM Stefan Claas
 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
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: WKD for GitHub pages

2021-01-08 Thread Stefan Claas via Gnupg-users
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
 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 'ste...@sac001.github.io'
>
> 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
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


WKD for GitHub pages

2021-01-08 Thread Stefan Claas via Gnupg-users
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 'ste...@sac001.github.io'

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
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users