Preserving non-central and privacy with a "permission recording keyserver" (was: Launching a new keyserver on keys.openpgp.org!)

[Bernhard Reiter]

Am Dienstag 09 Juli 2019 14:37:05 schrieb Michał Górny via Gnupg-devel:
> On Tue, 2019-07-09 at 11:50 +0200, Bernhard Reiter wrote:

> somebody could upload a key with your data without
> your permission.  However, somebody can also upload an UID with your PII
> on it (name, even address, etc.) and some other e-mail address.  E-mail
> verification does not really solve the problem, and I think it's
> reasonable to assume goodwill and handle abuse directly.

If the person with the address can reasonably prove that this is his address,
you have a point of contact and can blacklist the pubkey.
Same as someone can prove that the contents is otherwise illegal, e.g. by 
presenting a valid court order that it is.


> > === Non-email ids

> > The server can publish it preliminary, until someone complains and then
> > we either adapt the detection algorithm, record a deletion for the pubkey
> > or manually trigger the permission request.

> Detection algorithms make little sense.  Do you really want to have
> different rules for people with common names, and with uncommon names?

This is a strategy of keeping the administrative work of a keyserver at a 
reasonable amount. The first cases will be manual (like above), but other 
cases will be automated. The only way to defend against a work overflow is to 
automate the automatic publishing rules and for those that match go back to 
manual verification. This does not prevent legitimate, anynomous use of some 
string in the uids, but it prevents automated abuse like base64 encoding the 
personal data.

> How are you going to detect people on photo IDs?

We also should limit the data on the userid to some byte length, but yes, if 
it gets an automated attack that personal data, like an email address gets 
encoded as png image, we might have to add a png decoder and an OCR at some 
point. The point of this strategy is that we only do it, once this attack 
really comes to place. And additionally, we try to get hold of the attacker
and sue her for interfering with a common infrastructure.

All together we are making it less attractive to attack the common 
infrastructure, because it would mean to get inventive and to beat the cheap 
algorithm with manual work each time.

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/20190710/af06f874/attachment.sig>