New keyserver at keys.openpgp.org - what's your take?

[Stefan Claas]

Konstantin Ryabitsev wrote:

> On Fri, Jun 14, 2019 at 05:25:05PM +0300, Teemu Likonen wrote:
> >> The current shortcoming is stripping third-party signatures. So Web 
> >> of
> >> Trust wouldn't work (for good reasons described in the FAQ [0]). For
> >> some people this may be surprising.
> >
> >It may turn out to be a good choice to leave other people's certificates
> >(third-party signatures) out. It seems to solve the storage abuse
> >problem and probably doesn't harm too much communities who need web of
> >trust. Generally web of trust works only in tight communities who can
> >really verify each other's keys. Such communities can easily distribute
> >their keys through their web site or other common resources.
> 
> This is harder than it seems, so inability to use 3rd-party signatures 
> is kind of a deal-breaker. E.g. if you consider a community like Linux 
> kernel, where only very few developers have @kernel.org identities, it 
> would be handy to have a keyserver that did all of the following:
> 
> 1. implement the regular --send-key --recv-key api
> 2. when accepting a --send-key, check to make sure at least one of the 
> uid's matches an allow-list of identities (for example, from a dump of 
> all authors/committers in linux.git)
> 3. perform email verification using the matching identity from #2
> 4. store all key data without stripping out 3rd-party signatures
> 
> I guess it would be easy enough to hack that into hagrid, but that would 
> mean a hard fork and I'd avoid that at all costs.

Maybe you can consider in the future at least to allow CA sigs.
Those would be only one sig per key and the CA signing keys
could be stored in your database as reference as well.

Currently 3 CAs come to mind: Governikus, Heise and CAcert.

Maybe other CAs will show up in the future if you model
would support it and then we don't have to deal with the
classical WoT anymore.

Well, only a suggestion!

Regards
Stefan