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

[Bernhard Reiter]

Hello friends of GnuPG!

Am Mittwoch 12 Juni 2019 18:53:50 schrieb Vincent Breitmoser:
> the Hagrid team is pleased to announce the launch of our new keyserver,
> running at keys.openpgp.org!

It is good to see new code for distributing pubkeys for OpenPGP in general.

Hagrid's design decisions seems to aim towards preserving privacy
by requiring a confirmation before personal data is published.
This is much like the General Data Protection Regulation (GDPR).

> * Identities are only published with consent, while
>   non-identity information is freely distributed. 
> * Deletable. Users can delete personal information with a simple e-mail
>   confirmation.

And a simple implementation of this would make the service central, inheriting 
the drawbacks of a validating, central keyserver. "Central" in the meaning 
that one place decides if a user id of a pubkey (and the pubkey itself) is 
made available or not.

Another drawback as far as I can see is limiting the IDs that can be published 
towards email addresses, which makes it harder for non-email use cases of 
OpenPGP. 

Can we write a keyserver-software that avoid these two drawbacks?

What about the following idea:

== 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 the other case a keyserver gets a key and uid from a different server
and records from which one. It is avoided that each independent keyserver has 
to ask again.

Now if someone complains, a server operator can either point to the other 
keyserver or the permission they have recorded themselfs.

=== 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.

This way we can have independent keyservers, and it is clear that the network 
in non-validating as a rouge keyserver may claim to have recorded permissions
or deletions. However if a keyserver does real malice, it will get pointed to 
and is liable. It may also be blocked.

=== 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.

Someone who claims that this is their personal data, will have to do this with 
contact information and an understandable explanation why this is personal 
data. In the  beginning there maybe some interesting encodings and manual 
cases to consider, but after a short while the detection algorithms will 
catching most encodings.

=== How about the GDPR?

This idea accepts the assumption that we really need approval for publishing
an id that contains personal data (aka opt-in). Especially that the EU GDPR 
actually  is applicable in this case. I'm not sure if this is the case.
What I am quite sure about is that searching for an email address is okay,
if the search engine as recorded the information from a place where the 
permission can be safely assumed, for example from a personal homepage in the 
web. So once there is a chain of responsibility that can be followed in 
exceptional cases, this is fine as the rights of users are honored.


== Conclusion
While this is just an idea, yet, it seems possible to keep a searchable public 
and independently federated directory of pubkeys by design. Maybe hagrid can 
be used as basis for such an implementation.

Whether such a directly is useful as an addition to WKD in the long run is not
discussed. And tthe recent attack on the SKS keyserver network should not put 
pressure on this important discussion, in my opinion.

Best Regards,
Bernhard
ps.: Dominik and Andre are getting a copy, because I have voiced that idea to 
them on the phone in the last days. You do not need to include them in 
follow-ups.
pps.: I was unable to read all the writings about the hagrid approach so far. 
These days I need good, balances summaries to get on speed on some debates.
However got the impression that the idea is interesting enough to be written 
down rather sooner than later. 

-- 
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/f0da9663/attachment-0001.sig>