From wk at gnupg.org Tue Mar 3 15:47:58 2020 From: wk at gnupg.org (Werner Koch) Date: Tue, 03 Mar 2020 15:47:58 +0100 Subject: Invitation to the GnuPG e.V. general meeting 2020 In-Reply-To: <20200227162239.GA3270334@fripost.org> (Guilhem Moulin's message of "Thu, 27 Feb 2020 17:22:39 +0100") References: <87h818jyyd.fsf@wheatstone.g10code.de> <20200227162239.GA3270334@fripost.org> Message-ID: <87h7z5trz5.fsf@wheatstone.g10code.de> On Thu, 27 Feb 2020 17:22, Guilhem Moulin said: > I couldn't attend unfortunately, are the minutes available somewhere? That reminds me that I should urgently finish the editing of the minutes. I'll send them around asap. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bernhard at intevation.de Sat Mar 7 17:15:39 2020 From: bernhard at intevation.de (Bernhard Reiter) Date: Sat, 07 Mar 2020 17:15:39 +0100 Subject: Proposal: Let us run a keyserver Message-ID: <2097109.iZASKD2KPV@kymo.gruen> Dear Fellow friends of GnuPG, there has been a discussion between our members Daniel and Andre [1] which touched the point that we need more keyservers to be more decentral especially when thinking hkps and Tor. When looking at https://sks-keyservers.net/status/ we see only three Tor and four hkps servers. So what about rending a server and running a keyserver as e.V.? (Depending on what it takes, maybe we can find someone to sponsor the administration time necessary. Does someone know how much admin time it would take?) What do you think? Is this a good use of our resources? Best Regards, Bernhard [1] Search for "only three nodes" in https://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/2020-February/ 007720.html -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From phil.pennock at spodhuis.org Sun Mar 8 00:38:36 2020 From: phil.pennock at spodhuis.org (Phil Pennock) Date: Sat, 7 Mar 2020 18:38:36 -0500 Subject: Proposal: Let us run a keyserver In-Reply-To: <2097109.iZASKD2KPV@kymo.gruen> References: <2097109.iZASKD2KPV@kymo.gruen> Message-ID: <20200307233835.GA27170@breadbox.private.spodhuis.org> On 2020-03-07 at 17:15 +0100, Bernhard Reiter wrote: > When looking at https://sks-keyservers.net/status/ > we see only three Tor and four hkps servers. > > So what about rending a server and running a keyserver as e.V.? > (Depending on what it takes, maybe we can find someone to sponsor the > administration time necessary. Does someone know how much admin time it would > take?) I ran a keyserver for about 8 years, I wrote most of the operational documentation and debugged a lot of problems for people. Most of the time, the operational overhead was minimal. Until it wasn't, as people started deliberately trying to destroy the keyserver network. There are folks who think that the keyserver network should not exist, so they sponsor (EFF) or directly develop (others) tools to destroy it, to prove their point and push an agenda of one of the other crypto ecosystem tools. (If you take venture capitalist money, you need there to not be free alternatives which are better than what you're selling; if those alternatives are vulnerable to attack, well ... sooner or later, one of those companies is going to be less ethical than the others.) > What do you think? > Is this a good use of our resources? The keyserver network is a public append-only filesystem. This is not compatible with strong privacy law. The first keyserver to be hit by this was Peter Palfrader's, about the time I first got involved, a decade ago, when an Austrian filed a take-down notice to remove their "personal details" (name and email address) and Mr Palfrader decided that his only option, short of fighting a losing legal battle, was to shut down. I'm now American and my reaction to people gloating about how the GDPR would make the keyservers impossible was to move my keyserver to the USA. But then people released tools to make it easy to encode images and store them across a bunch of keys and signatures. At which point, we're looking at the legal implications of what DKG in his abuse-resistant keystore draft calls "toxic data" -- a *very* good name for it. I think that the public keyservers fulfilled a social need for a long time, but that their time has passed. I think that their existence provided a crutch which kept us from developing alternatives which properly protect participants. The toxic swamp that is the collection of keys in the public keyservers has undermined faith in OpenPGP as people persist in trying to find ways to avoid needing to bother with trusted introduction and the web-of-trust. One time, I had to turn on request logging to debug an operational problem. More than 50% of requests were for one key, relating to the MongoDB if I recall correctly, and asking around this was not a new state of affairs. The reward system of the public keyservers is broken; it's not supporting individuals as much as it's supporting sloppy build systems and businesses which try to externalize as many costs as possible, no matter how much it costs others. I think that the Verein's resources are better spent pushing next-generation keyserving facilities. The WKD stuff is good, a better UI on it might help. Abuse resistant keystores would be good. Migration strategies to help wean people off their addiction to the public keyservers would be good. Perhaps guest blog posts from people who work on infrastructure for various projects, writing about their experiences setting up key handling for their projects? * Debian is using WKD; how, what was involved in setting it up? * Gentoo is using WKD and stuff in human web-pages; what is the infrastructure behind this, how can others replicate it? * kernel.org has WKD and a git repo with keys for the Linux kernel maintainers; I would welcome articles by Konstantin Ryabitsev talking about his experiences herding cats here. Even without WKS, WKD provides a nice stable predictable naming convention for federated HTTPS-based key access. What might be good is some kind of optional update notification standard for WKD, so that people can register interest to get push notifications via webhooks or something else when there's an update. A pubsub system which tracks updates to WKD via those updates and maintains an anonymising layer so that domain operators don't get to see all the people interested in keys, with TOR gateways and other such facilities, might be something worth exploring; it could support more than WKD, but would stick to the idea that someone is accountable for any key present and keys can disappear over time. Heck, if the notification can include the full key as part of the payload, you could auto-ingest the keys directly without needing to connect back (but it would require signing the payloads with a shared secret to prevent injection attacks); that gets you closer to being able to recreate something like the SKS network, if you want. There are many options for how the GnuPG Verein should expend its resources. I assert that trying to resurrect the SKS network is a case of living in the past when we should be trying to build the future. The future the Verein supports should be one without gatekeepers who can extract rents, but one which is still accountable and isn't designed to require that people host toxic data in an all-or-nothing proposition. -Phil -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: Digital signature URL: From bernhard at intevation.de Mon Mar 9 10:36:41 2020 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 9 Mar 2020 10:36:41 +0100 Subject: Proposal: Let us run a keyserver In-Reply-To: <20200307233835.GA27170@breadbox.private.spodhuis.org> References: <2097109.iZASKD2KPV@kymo.gruen> <20200307233835.GA27170@breadbox.private.spodhuis.org> Message-ID: <202003091036.46556.bernhard@intevation.de> Hi Phil, Am Sonntag 08 M?rz 2020 00:38:36 schrieb Phil Pennock: > On 2020-03-07 at 17:15 +0100, Bernhard Reiter wrote: > > So what about rending a server and running a keyserver as e.V.? > I ran a keyserver for about 8 years, I wrote most of the operational > documentation and debugged a lot of problems for people. thanks for your long termin contributions to the keyserver network! :) [In my view our intern Verein mailinglist should only see limited discussions. Many topics are worth to be discussed in a wider circle. This is why I answer briefly and try refer to public mails. I'd appreciate other Verein members short feedback on the proposal.] > The keyserver network is a public append-only filesystem. This is not > compatible with strong privacy law. In my post Preserving non-central and privacy with a "permission recording keyserver" [Reiter 2019-07 a] https://lists.gnupg.org/pipermail/gnupg-devel/2019-July/034399.html there is a concept allowing for compatibility with strong privacy laws. > I think that the public keyservers fulfilled a social need for a long > time, but that their time has passed. My case why public keyservers should be preserved is Web of Trust's usefulness [Reiter 2019-07 c] https://lists.gnupg.org/pipermail/gnupg-devel/2019-July/034412.html | as additional source of trust and history. | Abandoning the web of trust common infrastructure works against usage | models where there is anonymous usage, several identities, non-email use | and offline usage. All those maybe not the majority case, they may even be | niche models, but I think they are important to add diversity and | resiliance against manipulations of mainstream players. (spelling improved) A third post of mine showed how we could conceptually preserve third party signature information on public servers: Preserving third party signatures distribution [Reiter 2019-07 b] https://lists.gnupg.org/pipermail/gnupg-devel/2019-July/034394.html > I think that the Verein's resources are better spent pushing > next-generation keyserving facilities. The WKD stuff is good, a better > UI on it might help. Abuse resistant keystores would be good. As Verein, we could do both to an extend. [And in this proposal I focus on the public keyserver.] > I assert that trying to resurrect the SKS network is a case > of living in the past when we should be trying to build the future. Preserving something important is a task that is well suited for a Verein, because it can do long running and neutral things. Look like the the state of the number of public keyservers and who were running was used as arguments in the debate I've pointed to. Verein would be in a good position to at least be one trusted operator of a public keyserver. Regards, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From gnupg at smolinski.name Mon Mar 9 19:12:56 2020 From: gnupg at smolinski.name (gnupg at smolinski.name) Date: Mon, 9 Mar 2020 19:12:56 +0100 Subject: Proposal: Let us run a keyserver In-Reply-To: <20200307233835.GA27170@breadbox.private.spodhuis.org> References: <2097109.iZASKD2KPV@kymo.gruen> <20200307233835.GA27170@breadbox.private.spodhuis.org> Message-ID: Thanks Phil, for your comprehensive comment. Here are my 2cts: In principle, keyservers have been a good idea to establish the web of trust. And they still would be, if there was sufficient trust and a sufficiently strong web. What I see going on for some 10 years is, that the strict verification of identities in the web of trust decreasingly relies on public endorsements. I can see two centers of gravity for confidential communication in the world: 1) Pseudonymous communication which should be protected against wiretapping. Usually peers have no real trust in the identity of the other side, only that she is "the same as last time". 2) Truly private communication among well known peers, who are very sure about the identity of the other side. Usually they exchanged keys before and wouldn`t rely on any public certificate arbitrated through untrusted partners. For case 2) mong peers which have never met before, S/MIME endorsed by public authorities might be (slightly) more reliable than a public web of trust. For case 1) autocrypt does the job. Keyservers could do it either, but, as Phil states, there are prohibiting legal issues in Europe. In other countries keyservers might disclose relationships in a machine readable way, which should require some work to investigate. Generally, I wouldn't see a great future for keyservers at all, regardless whether we run one or not. Probably communities will setup their own private keyservers - providing comprehensive docs about how to do this might be doing better to support private communication than investing effort and money into a backbone, that will hardly be used. Just my 2cts, Holger Am 08.03.20 um 00:38 schrieb Phil Pennock: > On 2020-03-07 at 17:15 +0100, Bernhard Reiter wrote: >> When looking at https://sks-keyservers.net/status/ >> we see only three Tor and four hkps servers. >> >> So what about rending a server and running a keyserver as e.V.? >> (Depending on what it takes, maybe we can find someone to sponsor the >> administration time necessary. Does someone know how much admin time it would >> take?) > > I ran a keyserver for about 8 years, I wrote most of the operational > documentation and debugged a lot of problems for people. > > Most of the time, the operational overhead was minimal. Until it > wasn't, as people started deliberately trying to destroy the keyserver > network. > > There are folks who think that the keyserver network should not exist, > so they sponsor (EFF) or directly develop (others) tools to destroy it, > to prove their point and push an agenda of one of the other crypto > ecosystem tools. > > (If you take venture capitalist money, you need there to not be free > alternatives which are better than what you're selling; if those > alternatives are vulnerable to attack, well ... sooner or later, one of > those companies is going to be less ethical than the others.) > >> What do you think? >> Is this a good use of our resources? > > The keyserver network is a public append-only filesystem. This is not > compatible with strong privacy law. The first keyserver to be hit by > this was Peter Palfrader's, about the time I first got involved, a > decade ago, when an Austrian filed a take-down notice to remove their > "personal details" (name and email address) and Mr Palfrader decided > that his only option, short of fighting a losing legal battle, was to > shut down. > > I'm now American and my reaction to people gloating about how the GDPR > would make the keyservers impossible was to move my keyserver to the > USA. But then people released tools to make it easy to encode images > and store them across a bunch of keys and signatures. At which point, > we're looking at the legal implications of what DKG in his > abuse-resistant keystore draft calls "toxic data" -- a *very* good name > for it. > > I think that the public keyservers fulfilled a social need for a long > time, but that their time has passed. I think that their existence > provided a crutch which kept us from developing alternatives which > properly protect participants. The toxic swamp that is the collection > of keys in the public keyservers has undermined faith in OpenPGP as > people persist in trying to find ways to avoid needing to bother with > trusted introduction and the web-of-trust. > > One time, I had to turn on request logging to debug an operational > problem. More than 50% of requests were for one key, relating to the > MongoDB if I recall correctly, and asking around this was not a new > state of affairs. The reward system of the public keyservers is broken; > it's not supporting individuals as much as it's supporting sloppy build > systems and businesses which try to externalize as many costs as > possible, no matter how much it costs others. > > I think that the Verein's resources are better spent pushing > next-generation keyserving facilities. The WKD stuff is good, a better > UI on it might help. Abuse resistant keystores would be good. > > Migration strategies to help wean people off their addiction to the > public keyservers would be good. > > Perhaps guest blog posts from people who work on infrastructure for > various projects, writing about their experiences setting up key > handling for their projects? > > * Debian is using WKD; how, what was involved in setting it up? > * Gentoo is using WKD and stuff in human web-pages; what is the > infrastructure behind this, how can others replicate it? > * kernel.org has WKD and a git repo with keys for the Linux kernel > maintainers; I would welcome articles by Konstantin Ryabitsev talking > about his experiences herding cats here. > > Even without WKS, WKD provides a nice stable predictable naming > convention for federated HTTPS-based key access. What might be good is > some kind of optional update notification standard for WKD, so that > people can register interest to get push notifications via webhooks or > something else when there's an update. > > A pubsub system which tracks updates to WKD via those updates and > maintains an anonymising layer so that domain operators don't get to see > all the people interested in keys, with TOR gateways and other such > facilities, might be something worth exploring; it could support more > than WKD, but would stick to the idea that someone is accountable for > any key present and keys can disappear over time. > > Heck, if the notification can include the full key as part of the > payload, you could auto-ingest the keys directly without needing to > connect back (but it would require signing the payloads with a shared > secret to prevent injection attacks); that gets you closer to being able > to recreate something like the SKS network, if you want. > > > There are many options for how the GnuPG Verein should expend its > resources. I assert that trying to resurrect the SKS network is a case > of living in the past when we should be trying to build the future. > > The future the Verein supports should be one without gatekeepers who can > extract rents, but one which is still accountable and isn't designed to > require that people host toxic data in an all-or-nothing proposition. > > -Phil > > > _______________________________________________ > Verein mailing list > Verein at gnupg.org > http://lists.gnupg.org/mailman/listinfo/verein > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 554 bytes Desc: OpenPGP digital signature URL: From bernhard at intevation.de Fri Mar 20 14:43:05 2020 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 20 Mar 2020 14:43:05 +0100 Subject: Proposal: Let us run a keyserver In-Reply-To: References: <2097109.iZASKD2KPV@kymo.gruen> <20200307233835.GA27170@breadbox.private.spodhuis.org> Message-ID: <202003201443.10225.bernhard@intevation.de> Hello Holger, thanks for your remarks! Am Montag 09 M?rz 2020 19:12:56 schrieb gnupg at smolinski.name: > Generally, I wouldn't see a great future for keyservers at all, > regardless whether we run one or not. Have you had a change to read the arguments for preserving a public keyserver network (linked from my previous email)? What do others think? Best Regards, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: