Discussion:
[Sks-devel] Implications of GDPR
Fabian A. Santiago
2018-04-29 10:24:03 UTC
Permalink
So,

As I understand it, GDPR concerns all EU citizen users of a site, regardless of where the site is hosted. How does this affect keyservers? I've seen at least one server going offline due to it. Should I be concerned as an American keyserver host?
--

Fabian A. Santiago

OpenPGP:

0x643082042dc83e6d94b86c405e3daa18a1c22d8f (current key)
0x3c3fa072accb7ac5db0f723455502b0eeb9070fc (to be retired / revoked)
Moritz Wirth
2018-04-29 11:02:35 UTC
Permalink
Hi Fabian,

first of all, I am not a lawyer so you should not rely on my response as
it may be wrong :)

- The GDPR applies to all persons and companies who are located in the
EU or offering goods, services or who monitor the behavior of EU data
subjects - this means that all keyservers are affected regardless where
they are physically located. (https://www.eugdpr.org/gdpr-faqs.html)

- Personal Data includes Names, Photos, social posts, IP-Addresses.. (so
it seems that everything that can be connected to a person is included
here).

- The Right to be forgotten: People have the right to get their data
deleted if it is no longer necessary in relation to the purpose they
were collected. I think this means that if someone wants to have their
data deleted, you have to delete it - given the fact above that some
keys include personal name or even photos, you would be required to
delete them (even if you are in the USA). However, I am not sure - the
text says "the controller, taking account of available technology and
the cost of implementation, shall take reasonable steps, including
technical measures, to inform controllers which are processing the
personal data that the data subject has requested the erasure by such
controllers of any links to, or copy or replication of, those personal
data." <-- Given the fact that it is not possible to delete data from a
keyserver, I am not sure how this would be handled. (Same applies to for
reasons of public interest in the area of public health in accordance
with points (h) and (i) of Article 9(2) as well as Article 9(3) but I
didnt check on that). (https://gdpr-info.eu/art-17-gdpr/)

- I heard that you must sign (physical) contracts with data processing
companies (this may also include Google and Google Analytics, I am not
sure about Google Fonts etc but since Google gets your IP...) if you
share the data of your user with them (e.g using GA on your site).
("Controller will need to have in place an appropriate contract with any
other Controller that it jointly shares data with if that Controller
particularly is outside the EU."). Should not really matter (except for
Google Fonts) - at the end the use of Tracking services is up to the
keyserver admin itself
(https://www.netskope.com/blog/gdpr-data-processing-agreements/)

The first thing I would do is to include a checkbox in the webtemplate
that every person who queries or uploads a key via the webinterface
agrees to your data policy - in the data policy you should explain what
happens when a key is uploaded, that it is distributed to other
keyservers, (IPs are collected whatever you do) and that it is not
possible to delete keys once they are uploaded.

If someone has more information on this or something to correct feel
free to do so :)

Best regards,

Moritz
Post by Fabian A. Santiago
So,
As I understand it, GDPR concerns all EU citizen users of a site, regardless of where the site is hosted. How does this affect keyservers? I've seen at least one server going offline due to it. Should I be concerned as an American keyserver host?
--
Fabian A. Santiago
0x643082042dc83e6d94b86c405e3daa18a1c22d8f (current key)
0x3c3fa072accb7ac5db0f723455502b0eeb9070fc (to be retired / revoked)
_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel
c***@funderburg.me
2018-04-29 12:06:51 UTC
Permalink
My short response to all of that is: "meh".

Less briefly: Technically, I think you're right. The whole keyserver system doesn't appear to work at all against GDPR. But equally, a _system_ like ours doesn't seem a very likely target of any regulators. The law was mostly envisioned to keep *companies* in line - not a disparate collection of individuals running a service as a hobby. After all, most European countries already had existing individual privacy laws that the keyservers were theoretically already in breach of.

I'll personally risk it - but as you note - I'm not a lawyer either. 😉

Regards,
Chris


-----Original Message-----
From: Sks-devel [mailto:sks-devel-bounces+chris=***@nongnu.org] On Behalf Of Moritz Wirth
Sent: 29 April 2018 12:03
To: Fabian A. Santiago <***@garbage-juice.com>; sks-devel <sks-***@nongnu.org>
Subject: Re: [Sks-devel] Implications of GDPR

Hi Fabian,

first of all, I am not a lawyer so you should not rely on my response as it may be wrong :)

- The GDPR applies to all persons and companies who are located in the EU or offering goods, services or who monitor the behavior of EU data subjects - this means that all keyservers are affected regardless where they are physically located. (https://www.eugdpr.org/gdpr-faqs.html)

- Personal Data includes Names, Photos, social posts, IP-Addresses.. (so it seems that everything that can be connected to a person is included here).

- The Right to be forgotten: People have the right to get their data deleted if it is no longer necessary in relation to the purpose they were collected. I think this means that if someone wants to have their data deleted, you have to delete it - given the fact above that some keys include personal name or even photos, you would be required to delete them (even if you are in the USA). However, I am not sure - the text says "the controller, taking account of available technology and the cost of implementation, shall take reasonable steps, including technical measures, to inform controllers which are processing the personal data that the data subject has requested the erasure by such controllers of any links to, or copy or replication of, those personal data." <-- Given the fact that it is not possible to delete data from a keyserver, I am not sure how this would be handled. (Same applies to for reasons of public interest in the area of public health in accordance with points (h) and (i) of Article 9(2) as well as Article 9(3) but I didnt check on that). (https://gdpr-info.eu/art-17-gdpr/)

- I heard that you must sign (physical) contracts with data processing companies (this may also include Google and Google Analytics, I am not sure about Google Fonts etc but since Google gets your IP...) if you share the data of your user with them (e.g using GA on your site).
("Controller will need to have in place an appropriate contract with any other Controller that it jointly shares data with if that Controller particularly is outside the EU."). Should not really matter (except for Google Fonts) - at the end the use of Tracking services is up to the keyserver admin itself
(https://www.netskope.com/blog/gdpr-data-processing-agreements/)

The first thing I would do is to include a checkbox in the webtemplate that every person who queries or uploads a key via the webinterface agrees to your data policy - in the data policy you should explain what happens when a key is uploaded, that it is distributed to other keyservers, (IPs are collected whatever you do) and that it is not possible to delete keys once they are uploaded.

If someone has more information on this or something to correct feel free to do so :)

Best regards,

Moritz
Post by Fabian A. Santiago
So,
As I understand it, GDPR concerns all EU citizen users of a site, regardless of where the site is hosted. How does this affect keyservers? I've seen at least one server going offline due to it. Should I be concerned as an American keyserver host?
--
Fabian A. Santiago
0x643082042dc83e6d94b86c405e3daa18a1c22d8f (current key)
0x3c3fa072accb7ac5db0f723455502b0eeb9070fc (to be retired / revoked)
_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel
Klaus-Uwe Mitterer
2018-04-29 12:22:10 UTC
Permalink
Hi Moritz,

My understanding is that the section you quoted on the "right to be
forgotten" refers to the controller's (i.e. your) obligation to inform
_other_ controllers processing the data (in this case: other keyserver
operators who, through gossip, have a "copy or replication" of the
personal data) about the data subject's request for deletion. "Technical
measures" in this context would, for instance, be a way to automatically
propagate the deletion to other servers; as this is not possible, you
only have to take "reasonable steps" to inform others, like sending an
email to your peers. If somebody wants you to delete their data, you
will definitely have to delete it, regardless of how difficult this is
to achieve with SKS.

A whole different issue is how you would get a data subject's permission
to process their data in the first place, and how you would notify them
about the fact that you are processing their data, both of which are
required by the GDPR.

Regards

Klaus-Uwe
Post by Moritz Wirth
Hi Fabian,
first of all, I am not a lawyer so you should not rely on my response as
it may be wrong :)
- The GDPR applies to all persons and companies who are located in the
EU or offering goods, services or who monitor the behavior of EU data
subjects - this means that all keyservers are affected regardless where
they are physically located. (https://www.eugdpr.org/gdpr-faqs.html)
- Personal Data includes Names, Photos, social posts, IP-Addresses.. (so
it seems that everything that can be connected to a person is included
here).
- The Right to be forgotten: People have the right to get their data
deleted if it is no longer necessary in relation to the purpose they
were collected. I think this means that if someone wants to have their
data deleted, you have to delete it - given the fact above that some
keys include personal name or even photos, you would be required to
delete them (even if you are in the USA). However, I am not sure - the
text says "the controller, taking account of available technology and
the cost of implementation, shall take reasonable steps, including
technical measures, to inform controllers which are processing the
personal data that the data subject has requested the erasure by such
controllers of any links to, or copy or replication of, those personal
data." <-- Given the fact that it is not possible to delete data from a
keyserver, I am not sure how this would be handled. (Same applies to for
reasons of public interest in the area of public health in accordance
with points (h) and (i) of Article 9(2) as well as Article 9(3) but I
didnt check on that). (https://gdpr-info.eu/art-17-gdpr/)
- I heard that you must sign (physical) contracts with data processing
companies (this may also include Google and Google Analytics, I am not
sure about Google Fonts etc but since Google gets your IP...) if you
share the data of your user with them (e.g using GA on your site).
("Controller will need to have in place an appropriate contract with any
other Controller that it jointly shares data with if that Controller
particularly is outside the EU."). Should not really matter (except for
Google Fonts) - at the end the use of Tracking services is up to the
keyserver admin itself
(https://www.netskope.com/blog/gdpr-data-processing-agreements/)
The first thing I would do is to include a checkbox in the webtemplate
that every person who queries or uploads a key via the webinterface
agrees to your data policy - in the data policy you should explain what
happens when a key is uploaded, that it is distributed to other
keyservers, (IPs are collected whatever you do) and that it is not
possible to delete keys once they are uploaded.
If someone has more information on this or something to correct feel
free to do so :)
Best regards,
Moritz
Post by Fabian A. Santiago
So,
As I understand it, GDPR concerns all EU citizen users of a site, regardless of where the site is hosted. How does this affect keyservers? I've seen at least one server going offline due to it. Should I be concerned as an American keyserver host?
--
Fabian A. Santiago
0x643082042dc83e6d94b86c405e3daa18a1c22d8f (current key)
0x3c3fa072accb7ac5db0f723455502b0eeb9070fc (to be retired / revoked)
_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel
_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel
--
Klaus-Uwe Mitterer

Email: ***@kumi.email

XMPP: ***@kumi.zone
Twitter: @kumitterer
Threema: PEBXP4H3
Telegram: @kumitterer

Skype: kumitterer
Mobile: +43 660 6340166

*** DISCLAIMER ***
This document is only intended for the person to whom it is
addressed. If you have received it, it was obviously addressed to you.
Therefore, you are free to read it, even if I didn't mean to send it to
you. However, if the contents of this email sound gibberish to you, you
were probably not the intended recipient - or you're just a mindless
cretin. If either is the case, you should immediately delete yourself
and destroy your computer. After doing this, please contact me
immediately. Well, obviously you can't use your computer for this, as
you have destroyed it. Also, you deleted yourself. Sorry, I digress...

In case I didn't send this email to you, I sincerely apologize. In
case of non-receipt of this email, I do not take any responsibility,
because it means that either you or your email provider or both use a
Microsoft Windows operating system. You know how glitchy that is, right?

Nor will I accept any liability, tacit or implied, for any damage
you may or may not incur as a result of receiving, or not, as the case
may be, from time to time, notwithstanding all liabilities implied or
otherwise and... erm... you know... whatever the case may be... IT
WASN'T ME. YOU'RE MEAN.
robots.txt fan
2018-04-29 15:08:59 UTC
Permalink
Post by c***@funderburg.me
Given the fact that it is not possible to delete data from a keyserver
Of course this is possible. You can delete key by using the "sks drop <hash>" command. Now, if I understand it correctly the key will immediately be re-added because of gossiping keyservers. However, it would not be impossible to extend SKS to have a keyserver reject keys from a blacklist that each server admin would maintain, or possibly gossip. (If this does not exist already.)

I imagine this would be a useful instrument for more use-cases than this one. I imagine a server admin based in Germany would get in trouble if someone submitted a key with the user-id "The owner of this server denies the Holocaust", an action that is illegal in Germany. The server admin could get out of the trouble by adding the hash of that key to the blacklist.

I know I am suggesting censorship but it's not like SKS was ever meant to be a secure or reliable channel.
Moritz Wirth
2018-04-29 16:20:13 UTC
Permalink
That does not solve the problem with the data deletion - the key id can be tracked to a person and would be therefore considered as personal Information so you would be still required to delete the key id itself.

The other big problem is the data sharing over reconciliation and other methods - you need the agreement by the user and all peering partners to do this - so you have to tell the user that you store his data regardless if he uses the website ( which would be easy) or the pgp client and it might be possible that you need the possibility to opt out of the reconprocess

The last thing is about data protection - I am pretty sure the data in the reconciliation process is not encrypted (which would be useless for public data) but may also be required for data exchanges by GDPR - the same goes for retrieval over https (which is tbh not really supported)

Sent from my iPhone
Post by robots.txt fan
Post by c***@funderburg.me
Given the fact that it is not possible to delete data from a keyserver
Of course this is possible. You can delete key by using the "sks drop <hash>" command. Now, if I understand it correctly the key will immediately be re-added because of gossiping keyservers. However, it would not be impossible to extend SKS to have a keyserver reject keys from a blacklist that each server admin would maintain, or possibly gossip. (If this does not exist already.)
I imagine this would be a useful instrument for more use-cases than this one. I imagine a server admin based in Germany would get in trouble if someone submitted a key with the user-id "The owner of this server denies the Holocaust", an action that is illegal in Germany. The server admin could get out of the trouble by adding the hash of that key to the blacklist.
I know I am suggesting censorship but it's not like SKS was ever meant to be a secure or reliable channel.
_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel
Ari Trachtenberg
2018-04-29 17:02:56 UTC
Permalink
Post by Moritz Wirth
The last thing is about data protection - I am pretty sure the data in the reconciliation process is not encrypted (which would be useless for public data) but may also be required for data exchanges by GDPR - the same goes for retrieval over https (which is tbh not really supported)
I don’t remember whether sks uses a single-stage or two-stage process for reconciliation 
 in a single-stage
process, data is directly encoded as evaluations of a rational function, so only another peer with similar
data will be able to decode it.

In a two-stage process, the initial phase is done on hashes, and a second stage transfers the data corresponding
to differing hashes. It should be possible for the second stage can be sent over an encrypted tunnel without
too much effort.

best,
-Ari
Post by Moritz Wirth
Sent from my iPhone
Post by robots.txt fan
Post by c***@funderburg.me
Given the fact that it is not possible to delete data from a keyserver
Of course this is possible. You can delete key by using the "sks drop <hash>" command. Now, if I understand it correctly the key will immediately be re-added because of gossiping keyservers. However, it would not be impossible to extend SKS to have a keyserver reject keys from a blacklist that each server admin would maintain, or possibly gossip. (If this does not exist already.)
I imagine this would be a useful instrument for more use-cases than this one. I imagine a server admin based in Germany would get in trouble if someone submitted a key with the user-id "The owner of this server denies the Holocaust", an action that is illegal in Germany. The server admin could get out of the trouble by adding the hash of that key to the blacklist.
I know I am suggesting censorship but it's not like SKS was ever meant to be a secure or reliable channel.
_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel
_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel
---
Prof. Ari Trachtenberg ECE, Boston University
***@bu.edu http://people.bu.edu/trachten
H Visage
2018-04-29 17:27:07 UTC
Permalink
Post by Moritz Wirth
The last thing is about data protection - I am pretty sure the data in the
reconciliation process is not encrypted (which would be useless for public
data) but may also be required for data exchanges by GDPR - the same goes
for retrieval over https (which is tbh not really supported)
I don’t remember whether sks uses a single-stage or two-stage process for
reconciliation 
 in a single-stage
process, data is directly encoded as evaluations of a rational function,
so only another peer with similar
data will be able to decode it.
In a two-stage process, the initial phase is done on hashes, and a second
stage transfers the data corresponding
to differing hashes. It should be possible for the second stage can be
sent over an encrypted tunnel without
too much effort.
And then the data is requested over HTTP unencrypted by the pgp-client or
web interface
Post by Moritz Wirth
best,
-Ari
Sent from my iPhone
Given the fact that it is not possible to delete data from a keyserver
Of course this is possible. You can delete key by using the "sks drop
<hash>" command. Now, if I understand it correctly the key will immediately
be re-added because of gossiping keyservers. However, it would not be
impossible to extend SKS to have a keyserver reject keys from a blacklist
that each server admin would maintain, or possibly gossip. (If this does
not exist already.)
I imagine this would be a useful instrument for more use-cases than this
one. I imagine a server admin based in Germany would get in trouble if
someone submitted a key with the user-id "The owner of this server denies
the Holocaust", an action that is illegal in Germany. The server admin
could get out of the trouble by adding the hash of that key to the
blacklist.
I know I am suggesting censorship but it's not like SKS was ever meant to
be a secure or reliable channel.
_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel
_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel
---
Prof. Ari Trachtenberg ECE, Boston University
_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel
Andrew Gallagher
2018-04-30 11:59:22 UTC
Permalink
Post by Ari Trachtenberg
In a two-stage process, the initial phase is done on hashes, and a
second stage transfers the data corresponding
to differing hashes.
Yes, that's exactly what happens. The missing entries are fetched over a
standard client request.
Post by Ari Trachtenberg
It should be possible for the second stage can be sent over an encrypted tunnel without
too much effort.
If the remote server supports HTTPS for client requests, then it would
be straightforward for the reconciliation client to also connect over
HTTPS - but it would have to either fall back to HTTP if the HTTPS
request failed, or be configured with a list of which of its peers are
HTTPS-enabled.

Certificate validation may also be an issue, because many HTTPS pool
members only have the pool SSL certificate - which won't validate in the
normal manner when bypassing the pool round-robin.
--
Andrew Gallagher
Kristian Fiskerstrand
2018-04-30 12:12:55 UTC
Permalink
Post by Andrew Gallagher
Certificate validation may also be an issue, because many HTTPS pool
members only have the pool SSL certificate - which won't validate in the
normal manner when bypassing the pool round-robin.
The certs includes CN and SANs for the keyserver, so it could still be
used in this scenario, actually. The SNI setups I've seen with deviating
handling use e.g letsencrypt cert when doing direct keyserver request,
but that would still validate.

But you'd potentially also have issues with keydumps as well as split
pools serving different keyblocks depending on which server you hit - so
I believe the underlying question is more complex than just throwing
https on it, although it is certainly possible to do so.

Immediately it sounds like just increasing the overhead without much
value added though (the data is public anyways), but the whole GDPR is a
mess to begin with.
--
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
"Expect the best. Prepare for the worst. Capitalize on what comes."
(Zig Ziglar)
Mike O'Connor
2018-05-03 06:18:11 UTC
Permalink
Post by Fabian A. Santiago
So,
As I understand it, GDPR concerns all EU citizen users of a site, regardless of where the site is hosted. How does this affect keyservers? I've seen at least one server going offline due to it. Should I be concerned as an American keyserver host?
--
Fabian A. Santiago
0x643082042dc83e6d94b86c405e3daa18a1c22d8f (current key)
0x3c3fa072accb7ac5db0f723455502b0eeb9070fc (to be retired / revoked)
_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel
I'm thinking the problem is much simpler than its being made out to be.
For the data to have got in to the SKS system the user must push it
there. Its not like we are gathering the data in the background like FB
or Google, so its the users responsibility control the data and delete
it if needed.

I do think the SKS system need a way of being told by a key owner that
they want the data to be deleted, this then get propagated as an update.
Once all the peers of an SKS Server know about a deletion request all
the data (including the key could be deleted).

There might be a problem with a re-add loop even with the above rule so
maybe a local black list might be needed.

Any how my 2 cents worth

Mike
Gabor Kiss
2018-05-03 07:35:11 UTC
Permalink
Post by Mike O'Connor
I'm thinking the problem is much simpler than its being made out to be.
For the data to have got in to the SKS system the user must push it
there. Its not like we are gathering the data in the background like FB
Actually anybody can send in your name and e-mail address (with a fake key
of course).
Post by Mike O'Connor
or Google, so its the users responsibility control the data and delete
it if needed.
IMHO the current form of key servers won't survive the GDPR.
We have to destroy it then to rebuild from scratch.

My suggestion a key server should accept keys only with a special
ID record:
"This is a public information as written on http://gdpr.example.com"
or so. That is signed by owner. Whose identity is verified by someone else.
So key server is a toy for the strong set only. At least in the first
few years.

Gabor
Ari Trachtenberg
2018-05-03 11:26:17 UTC
Permalink

 or keep sks servers out of Europe.
Post by Gabor Kiss
Post by Mike O'Connor
I'm thinking the problem is much simpler than its being made out to be.
For the data to have got in to the SKS system the user must push it
there. Its not like we are gathering the data in the background like FB
Actually anybody can send in your name and e-mail address (with a fake key
of course).
Post by Mike O'Connor
or Google, so its the users responsibility control the data and delete
it if needed.
IMHO the current form of key servers won't survive the GDPR.
We have to destroy it then to rebuild from scratch.
My suggestion a key server should accept keys only with a special
"This is a public information as written on http://gdpr.example.com"
or so. That is signed by owner. Whose identity is verified by someone else.
So key server is a toy for the strong set only. At least in the first
few years.
Gabor
_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel
---
Prof. Ari Trachtenberg ECE, Boston University
***@bu.edu http://people.bu.edu/trachten
Moritz Wirth
2018-05-03 11:40:28 UTC
Permalink
That does not help because you still Store european data which is still affected by the GDPR.

What about only accepting valid keys and removing all revoked or expired keys from the database? If someone wants to have his data deleted he can revoke his key and the revoked signature is synced over all keyservers which then delete them from their own db - new revoked keys are simply rejected.

Sent from my iPad
Post by Ari Trachtenberg

 or keep sks servers out of Europe.
Post by Mike O'Connor
I'm thinking the problem is much simpler than its being made out to be.
For the data to have got in to the SKS system the user must push it
there. Its not like we are gathering the data in the background like FB
Actually anybody can send in your name and e-mail address (with a fake key of course).
Post by Mike O'Connor
or Google, so its the users responsibility control the data and delete
it if needed.
IMHO the current form of key servers won't survive the GDPR.
We have to destroy it then to rebuild from scratch.
My suggestion a key server should accept keys only with a special
"This is a public information as written on http://gdpr.example.com"
or so. That is signed by owner. Whose identity is verified by someone else.
So key server is a toy for the strong set only. At least in the first
few years.
Gabor
_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel
---
Prof. Ari Trachtenberg ECE, Boston University
_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel
Kiss Gabor (Bitman)
2018-05-03 12:10:14 UTC
Permalink
Post by Moritz Wirth
What about only accepting valid keys and removing all revoked or expired keys from the database? If someone wants to have his data deleted he can revoke his key and the revoked signature is synced over all keyservers which then delete them from their own db - new revoked keys are simply rejected.
Actually anybody can send in your name and e-mail address (with a fake key of course).
You cannot revoke a key with your name and address placed by someone else.

Gabor
Andrew Gallagher
2018-05-03 12:58:50 UTC
Permalink
Post by Moritz Wirth
What about only accepting valid keys and removing all revoked or expired
keys from the database?
I assume you mean "remove the user-id packets of all revoked or expired
keys"? You would have to retain at least the revocation signature and
the primary key, to make sure that nobody tried to re-upload a
non-revoked copy of the key, and to make sure that the keyservers still
served their primary purpose of distributing key revocations.

But the primary key could itself be considered personal data...
--
Andrew Gallagher
Fabian A. Santiago
2018-05-03 13:32:14 UTC
Permalink
Post by Andrew Gallagher
Post by Moritz Wirth
What about only accepting valid keys and removing all revoked or expired
keys from the database?
I assume you mean "remove the user-id packets of all revoked or expired
keys"? You would have to retain at least the revocation signature and
the primary key, to make sure that nobody tried to re-upload a
non-revoked copy of the key, and to make sure that the keyservers still
served their primary purpose of distributing key revocations.
But the primary key could itself be considered personal data...
_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel
i support the idea of local blacklists and being able to remove keys
upon request. but sadly i'm not a developer so i can't contribute to
such a cause.
--
--

Thanks,

Fabian S.

OpenPGP:

0x3C3FA072ACCB7AC5DB0F723455502B0EEB9070FC (to be revoked)
0x643082042DC83E6D94B86C405E3DAA18A1C22D8F (new key)
brent s.
2018-05-03 17:21:57 UTC
Permalink
Post by Moritz Wirth
That does not help because you still Store european data which is still
affected by the GDPR.
What about only accepting valid keys and removing all revoked or expired
keys from the database? If someone wants to have his data deleted he can
revoke his key and the revoked signature is synced over all keyservers
which then delete them from their own db - new revoked keys are simply
rejected. 
how do you determine the "validity" of a key? do you mean in the
technical sense (not expired, revoked, etc.)? because others have
pointed out the issue with that.

or do you mean proving a user owns a key they push? if so, that has its
own problems- sure, you could send an email to the email address
associated with the key and require a reply (such as what
keyserver.pgp.com did - does? haven't used in a while), BUT...

not all keys have addresses associated (and this is the preferred method
for addressing the - admittedly, in my opinion, unfounded but still
commonplace - concern of spammers harvesting email addresses from keys).
--
brent saner
https://square-r00t.net/
GPG info: https://square-r00t.net/gpg-info
Daniel Roesler
2018-05-03 18:04:10 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Is there any way we could look for a "sensitive" flag on a
revocation key packet[1]? "If this flag is set, implementations
SHOULD NOT export this signature to other users except in cases
where the data needs to be available."

[1]: https://tools.ietf.org/html/rfc4880#section-5.2.3.15

Here's some logic:

(1) Receive key via gossip or upload.
(2) Scan signatures for revocation key with "sensitive" flag.
(3) If present, see if revocation key is available in packets.
(4) If available, see if signing key is self-signature.
(5) If self-signature, validate the signature.
(6) If valid, drop the packet that the signature is signing.

Pros:
* Already built into OpenPGP spec.
* Cryptographically secure.
* Packet-level specific (e.g. can "forget" specific emails).

Cons:
* Possibly contorting original intent of the "sensitive" flag.
* Requires starting validating signatures (though this only
requires validating self-signatures, so no worries about
public key availability).
* Likely few clients offer easy-to-use capabilities of making
this type of revocation key signature.

Thoughts?

Daniel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJa607IAAoJEMtwcDcM6wt6J8UH/jM4AK4yeV1kp+lNfuBbM/6v
3N3vkozxirWyWc4cJjwXaFjMnreuNH3BAXHqNSQuVOFHrCMWmaiU2Cvn3IiMf8y7
5d6jDNG1wsaZNpaxRDyUAh4IFX0MbUQg71bhtKNczAl0MCOgEZL7dz2y5rez79b2
nTdTrRHvDHWOmjqZ491Wdsw3jcRGj1hMYHmg02SopOO2BW7qyv+bklFKoIyNNf2Z
tGkZI1Sg/9FFVfyo5ap1exaK4Fe+r2aeA/iTUE6TkDlhHrz7i8/tz2iZv9cYqLFE
ZRsKGOh7Pa88LRBN+ALVNXF0dExf/sgX+TlE0sHLw41Mg6iCUPRNnddrsmFvGiw=
=As7J
-----END PGP SIGNATURE-----
Post by brent s.
Post by Moritz Wirth
That does not help because you still Store european data which is still
affected by the GDPR.
What about only accepting valid keys and removing all revoked or expired
keys from the database? If someone wants to have his data deleted he can
revoke his key and the revoked signature is synced over all keyservers
which then delete them from their own db - new revoked keys are simply
rejected.
how do you determine the "validity" of a key? do you mean in the
technical sense (not expired, revoked, etc.)? because others have
pointed out the issue with that.
or do you mean proving a user owns a key they push? if so, that has its
own problems- sure, you could send an email to the email address
associated with the key and require a reply (such as what
keyserver.pgp.com did - does? haven't used in a while), BUT...
not all keys have addresses associated (and this is the preferred method
for addressing the - admittedly, in my opinion, unfounded but still
commonplace - concern of spammers harvesting email addresses from keys).
--
brent saner
https://square-r00t.net/
GPG info: https://square-r00t.net/gpg-info
_______________________________________________
Sks-devel mailing list
https://lists.nongnu.org/mailman/listinfo/sks-devel
dirk astrath
2018-05-04 08:44:31 UTC
Permalink
Hi,

It may make sense to keep a revoked key in our database:

How is your decision, if a key can't be found on a keyserver?

Trust on first use? Don't trust?

If my key gets compromised, I want to tell the community: DO NOT trust
this key ... so I revoke it.

Therefore:

If revoked (or expired) keys are removed from keyservers, I'm unable to
tell this anymore.


Another issue are the "fake" keys or keys, which have been uploaded a
looooong time ago.

Even if you're the owner (or former owner) of the
username/mailadress-combination you're unable to revoke the key or add
any (trusted) signature to this key so it will get removed (or unlisted).

So these key can't get removed from the database.

Well ... using any fake email-adress i would be able to write "somebody"
"please remove my key from keyserver", but ... how am I able to proof
that I'm the one who is allowed to get this key removed?
And ... even if I have to answer to a "ping"-mail: If the domain doesn't
exist anymore (or belongs to somebody else) I will not be able to answer
and therefore confirm the deletion.


All in all:

It's not easy to find a perfect solution (if there is any) ... and it's
not the first time we have this discussion ...

... the first time I remember it was after the talk on OHM 2013
"Trolling the Openpgp-Web-of-trust" ... unfortunately nothing changed
since then ... ;-(

Kind regards,

dirk
Arnold
2018-05-04 21:56:25 UTC
Permalink
Post by dirk astrath
How is your decision, if a key can't be found on a keyserver?
Trust on first use? Don't trust?
This should, IMO, all be a local, individual decision.

I am currently looking into 'value sensitive design', making systems that are
adjustable to specific human values in different human societies.
[ https://vsdesign.org/ ]
Post by dirk astrath
If my key gets compromised, I want ...
If ..., I'm unable to ...
In many messages in the current discussion, it is very easy to spot examples of a
need for value sensitive design, like in these few lines above.
Post by dirk astrath
It's not easy to find a perfect solution (if there is any) ... and it's
not the first time we have this discussion ...
In 2015, the idea came up to let go of the idea of a single set that gets
synchronised. Instead of one single set, we can define parametrised filters to
create 'value sensitive sets' ;-)
[ http://lists.nongnu.org/archive/html/sks-devel/2015-05/msg00062.html ]

If keyserver A has configured Set A and keyserver B has configured Set B, the set
reconciliation algorithm between keyservers A and B should only consider Set C,
where Set C is the intersection of sets A and B. The set reconciliation algorithm
can be used the same.

In case the operator of keyserver A finds that his Set A is "larger" than the union
of all Sets of its peers, that operator can ask on this very mailing list for
peering with keyservers that have the missing subset (based on the configured
parameters of the filters).

At least this might be a solution to the keyserver compatibility problem.


For the pool, we might end up with sub-pools based on filter parameters. If
operators don't do fancy filtering of their own, but follow local law, we might end
up with regional pools, possibly based on groups of countries, with a maximum of
the number of countries in the world ;-)

Kind regards,
Arnold
Andrew Gallagher
2018-05-05 00:08:22 UTC
Permalink
Post by Arnold
If keyserver A has configured Set A and keyserver B has configured Set B, the set
reconciliation algorithm between keyservers A and B should only consider Set C,
where Set C is the intersection of sets A and B. The set reconciliation algorithm
can be used the same
The main difference between this proposal and the one that Phil, myself and others are discussing in the other thread is that here the servers need to agree on the definition of these sets in advance, and servers that do not understand the sets (perhaps because they are too old) will be unable to recon with those that serve a restricted set.

The advantage of fake recon is that a) it can be deployed incrementally while maintaining recon between old and new software versions and b) there is no need for a commonly agreed definition of sets.

A

Loading...