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 <an...@colomb.de>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users