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

[Michał Górny]

On Tue, 2019-07-09 at 11:50 +0200, Bernhard Reiter wrote:
> == A permission recording keyserver
> 
> === Ask for permission to publish once
> A keyserver records where it got the user id from.
> If it is uploaded, and the id contains personal data, it knows which person's 
> data it is, thus this person can be asked for permission.
> Example, there is an email address in the id. Thus an email can be send to
> confirm the intend of the person to publish the pubkey. This permission is 
> recorded.

In my opinion, the whole e-mail hassle is unnecessary, and could be
resolved with appropriate privacy policy.  If someone decides to upload
the key with his own personal data on it, then that someone obviously
agrees with the personal data being shared.  As long as he can get that
data removed afterwards, there shouldn't be a problem with that.

That said, of course 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.

> 
> === Record deletions
> If someone requests a deletion (which means this person can prove that it is 
> there personal data), this is also recorded, only by key number, so this can 
> also be synced with other keyservers.

That generally makes sense.  Of course, the major problem is how to
prove.  You want to avoid abuse, e.g. when someone with coincidentally
the same name (or fake documents) tries to delete somebody else's key.

You probably should also have a way to revert the deletion requests.

> === Non-email ids
> If the iid does not contain an email address, it may or may not be data that 
> is personal. Example: "bernhard at intevation dot de" has personal data.
> Example: "Zilkin 2019-ahex" does not.
> 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.

See above.  I agree with the idea of publishing by default.  If we
really can't live with that, I think it would be reasonable to require
only one verified e-mail (as statement of consent), and allow other UIDs
on the same key by default.

Detection algorithms make little sense.  Do you really want to have
different rules for people with common names, and with uncommon names? 
How are you going to detect people on photo IDs?


-- 
Best regards,
Michał Górny

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 618 bytes
Desc: This is a digitally signed message part
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190709/817d8fa2/attachment.sig>