Preserving non-central and privacy with a "permission recording keyserver" (was: Launching a new keyserver on keys.openpgp.org!)
dirk.gottschalk1980 at googlemail.com
Tue Jul 9 14:13:36 CEST 2019
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.
> 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
> === 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
> 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
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
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.
GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part
More information about the Gnupg-devel