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

[Dirk Gottschalk]

Hello.

Am Dienstag, den 09.07.2019, 11:50 +0200 schrieb 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!

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

And central in the meaning of standing alone. :/

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

Right.

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

With Obama's words: Yes, we can!

I am thinking abour writing a new distributed key server now for a few
days. In my case, just for a company in house solution, but it would be
interwsting to make it a public solution. Respecting the GDPR was out
of scope in my case, but let's simply discuss, if you wish.


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

On sync, the key has just to be flagged if it is privacy protected, or
if it's IDs can be delivered. Yeah, that's a ghood point.


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

This could also be done while syncing. Just changing the Flag for KEy
0xABCDEF


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

Sure, technically not a big thing. 


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

Exactly my thoughts. I have some thoughts about how to realize such a
server, a little mir in Detail. I would like to discuss them, are you
interested? Would thos be okay here on the list?

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

That'S what I think to. We could even take the upload as implicated
consent on the legal state. But, the possibility to share keys without
UIDs is in some ways a good one. So you can habe ID-less keys for
automated operations where you don't need the UIDs. By the way, is
there a way to generate keys with GPG without UIDs? I tried, but I
failed. Did I oversee an CLI option to do this?


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

My approach would be different. Not using Hagrid. But that's another
story.


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

WKD is in some Cases kind of problematic. Think about users of gmail,
like me, they don't offer WKD at all. So, a second system is nice to
have.

Just a few lines Background: I work in some company projects, where
other companies are involved now. Until then, we propagated the keys we
use over DNS as CERT RRs.in our internal DNS-Server. Now this is no
longer an options. Relying hardly on PGP for many purposes and
usecases, we need a new way to propagate keys and sync them with the
other companies. LDAP would be an option, but making them public
available is not a good idea in aur eyes. A VPN is also out of question
for some reasons, even it would avoid the DNS-Problem.

If somebody wishes to get further details on my theoretical plans or to
discuss the whole thing from another side, I'm open to discussion.

Kind regards,
Dirk

-- 
Dirk Gottschalk

GPG: 4278 1FCA 035A 9A63 4166  CE11 7544 0AD9 4996 F380
Keybase: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac


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