Preserving third party signatures distribution (was: Launching a new keyserver on keys.openpgp.org!)

[Bernhard Reiter]

Hello friends of GnuPG!

> the Hagrid team is pleased to announce the launch of our new keyserver,

In this post an idea is outlined to preserve the common infrastructure
of distributing third party signatures. (It is related to my post about
'Preserving non-central and privacy with a "permission recording keyserver"'.)

Can we build up a keyserver infrastructure, without central control,
but where spam is kept at bay? 

What about:

== Some accountability, like email

With email there is a spam problem, but email still works and is 
decentralized. Usually email is accepted from all domains and servers 
(adhering to some rules.) More generally speaking it is a common 
infrastructure. And this has to be defended against attacks, which happens
via blacklists and even legal or police actions in case of email. For this to 
work for third party signature, we'd need some trails of the data and some 
responsibility. This seems possible - as with email. Though it means some 
work operating the keyserver network.

A server can record where the third pary signature came from, either an upload
or a different keyserver; and when. And then it can limit the number of third 
party signatures carried for one pubkey.

== Order more important information

Towards the limit of carried information about a pubkey, the most important
information should be delivered first, this means pubkey itself, revocation 
information, self-signed user ids. And then third pary signatures that have 
been authorised by the key owner (by a signature) and the remaining ones 
ordered in time that the keyserver has seen them.

So if flooding is attempted, it will only affect the remaining space
for additional pubkey information, but the important stuff is delivered first.
This avoids a denial of service attack.


== Occasionally record preference of third party signatures by key owner

If we have a network of permission recording keyservers, only one of them 
occasionally would need to receive a permission of the key owner to carry the 
third party signature. The others will just see the signature on the third 
party keys.

The limit is not a problem, if no attack is tried. Often there will be enough 
old third party signature for the system to work.

If an attack occurs and third party signatures are a problem, a key owner may  
# request a higher limit 
# request that some signatures are not being carried (by pattern or id)
# sign some third party keys

However this is only necessary in case of attacks. It is additional 
information in other cases, so it does not pose much work on the user 
(clients).


== No motivation for attacks

If there is a limit and an order for the distributed third party signatures, 
the motivation of attackers are lower, as people can defend themselfs and 
they are unable to interrupt the exchange of relevant third party keys. 

(Also I wonder what the motivation of the current attacks is.)

== Context

This does not discuss if having third party information outside of WKD 
repositories is useful in the long-term. The approach only tries to make 
technically possible what a significant number of people is using today
and some consider useful to have.

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: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190709/2ccdd2e3/attachment.sig>