WKD for GitHub pages

[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 <andre at colomb.de>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210112/f8c870e2/attachment-0001.sig>