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
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
Attached Files:
-
signature.asc (0.48 KB)