Mailing List Archive

Preserving third party signatures distribution (was: Launching a new keyserver on keys.openpgp.org!)
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