Proposal: Let us run a keyserver

[gnupg at smolinski.name]

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: <https://lists.gnupg.org/pipermail/verein/attachments/20200309/e763620d/attachment-0001.sig>