Re: [Sks-devel] About deleting keys
Hello, On 11/04/2013 10:14 AM, Johan van Selst wrote: > Petru Ghita wrote: >> But I don't really think that such a legal action is possible and >> assuming it was possible that it would have any degree of success. > [..] >> To sum it up: >> - there is by architecture no intent on verifing nor identifying the >> information stored on the SKS network nor the author of the data. > > It doesn't matter if the information is verified. Users are asked for > their name and email address, which is considered personal data > (according to EU definitions) and keyservers are processing and storing > this data. Thereby, keyserver operators are subjected to the data > protection laws. The validity of the data is not relevant, neither is > the intention of the operators (commercial or otherwise). Users are not asked for their name nor for their email address by the SKS implementation. Please check [1]. What I see there is a text field, that has no validation nor any standard format whatsoever that is used to identify a public key. For the matter of argument you could create a (valid and usable) key with an UID: "John who lives in front of Alice." This is the main argument any SKS operator has in front of a judge, in my opinion. The whole point being that there is no such thing as personal data stored in the UID. It is also true that some GUI implementation create kind of a standard string by composing what a user has on the fields name and email of their email account and use that as the data posted to an SKS server on the UID field. But again, that's a client thing. That client could be using twitter as a server for posting this kind of data for the sake of the argument, but that would not make twitter a personal information database. What I'm trying to show here is that I think there is quite strong evidence that a SKS server or the SKS network for that matter is just a storage and delivery media, same as a distributed web server or a web proxy cache. > If national or international data protection laws give users the right > to have their personal data removed from servers, then it should be > possible for local keyserver operators to comply with that law. > Preferably without terminating their service. If it would be considered that there is indeed personal data stored on the SKS servers, no matter if the "delete" functionality would be somehow implemented, there would be no way of running, legally an SKS server in Europe. There are some other issues we would need to deal with such as: - Giving EU citizens private data to third parties not bound by EU legislation. - Not having a proper security assessment of our peers servers, or of our own servers security for that matter. - There are more legislations than EU... there would be NO way that we would be able to know nor comply with each particular legislation about privacy. I'm quite sure that it is practically impossible to do that properly even with all the countries in the EU without investing huge amounts of time in the matter. > The privacy and data protection regulations are not the only thing to > worry about. If people put Nazi slogans or death threats into UID > fields, or put child pornography into JPEG attachments, then there may > be other laws that can force keyserver operators to remove keys. If I'd upload a picture with a swastika as the picture of the UID: "John who lives in front of Alice." - how would you know about the existence of such a picture? - if you'd somehow learn about it, because I'd give you the UID and you'd actually check it out: Would you remove it? Would you force me to remove it? On what grounds? Please look at [2] and note that the swastika was and still is a symbol for Good for some cultures. If we would remove all the symbols and information that is offensive to somebody in some degree from the Internet, we would end up with very little content in there. > IMHO there is a clear demand for the option to remove certain keys - > or at least make them irretrievable locally. That some keyserver > operators are asking for the feature, should be reason enough to move on > to discussion of the technical aspects. True, that it might be good to discuss the ability to delete/hide keys. But the big problem that have been highlighted and not solved, properly in my opinion is still there: The data has no owner therefore who should have the authority to delete or modify it. In this respect what comes to mind is Wikipedia. So you'd keep some old versions of the data and in the eventuality of vandalism you'd be able to recover a point in time version. But then you'd probably need a centralized model instead of a distributed one. Kind regards, Petru [1] http://www.gedanken.org.uk/pgp/ [2] http://en.wikipedia.org/wiki/Swastika signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Peering request
On 2013-11-04 at 22:36 +0100, Johan Bakker wrote: > Hi all, Hoi Johan, > I just finished a new SKS keyserver installation. The server is located > in the netherlands and connected by both IPv4 and IPv6. It may be, but SKS is not responding on the IPv6 address. It also doesn't _look_ as though you have a reverse proxy set up in front, which you might want to fix: SKS is single-threaded, request-at-a-time and prone to being DoS'd by a slow client, unless you set up an HTTP reverse proxy in front, to take responsibility for dealing with slow clients. There are more details on setup, with suggested configurations, at: https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering If you at least fix the IPv6, I'll be very happy to set up peering; my machine is in NL, on the Coloclue network. mvg, -Phil ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Possible solution to "delete" keys
Hi, > The issue now is, that a keyserver-operator in germany (and likely > europe) can be forced to shut down his server if he cannot delete a > single key from the database (or at least from the requests to the > database). after a (very short) talk with a lawyer, I'm not quite sure if this is true. Since my sks instance is also running on a machine located in germany, I'd be happy if you could add some link. Thanks! cheers, - Stephan signature.asc Description: This is a digitally signed message part ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] Peering request
Hi all, I just finished a new SKS keyserver installation. The server is located in the netherlands and connected by both IPv4 and IPv6. I've imported a dump and currently I have 3362707 keys in my database. I would like to add some peers (and feel free to add me as well). cheers, Johan Bakker keyserver.provonet.nl 11370 # Johan Bakker 80495D6F signature.asc Description: This is a digitally signed message part ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] About deleting keys
On Mon, 4 Nov 2013, robert.O wrote: > I think this is the openpgp and Gnupgp to modify the program and add: > > 1- revoke the key without deleting data > 2 - revoke the key and delete data > > *Then sks-server respect**the orders of the owner of the private key* Arnold wrote: | If I remember right, there was a situation that Alice created a key with the | name of Bob. Bob complained to the key server operator, but he is not able to | modify the key Alice created. So, the key server operator should be the one | who disables retrieval of the key. http://lists.nongnu.org/archive/html/sks-devel/2013-10/msg00059.html: Gabor ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] About deleting keys
Hi, > This is not the sks-server to decide whether the key or data needs to > be modified or suppressed. > The danger is that someone or organistaion manipulates a sks server > for others to accept without audits. I think it's not about the risk of keyserver "manipulation", it's about the presence of faked keys. If I get the last lawsuite right, the payload of someones key with a faked email address was problematic. > I think this is the openpgp and Gnupgp to modify the program and add: > > 1- revoke the key without deleting data > 2 - revoke the key and delete data > Then sks-server respect the orders of the owner of the private key For legitimate owners that's the usual way. The worst scenario would be if someone lost it's private key, and is subsequently unable to revoke the public one. Personally, I'm currently very undecided how (or even if) the keyservers could prevent misusage. I have to talk with some of my collegues, one of them happens to be lawyer. I'll get back to the list, after getting more informations ;) cheers, - Stephan signature.asc Description: This is a digitally signed message part ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] About deleting keys
This is not the sks-server to decide whether the key or data needs to be modified or suppressed. The danger is that someone or organistaion manipulates a sks server for others to accept without audits. I think this is the openpgp and Gnupgp to modify the program and add: 1- revoke the key without deleting data 2 - revoke the key and delete data *Then sks-server respect**the orders of the owner of the private key* Excuse my bad english robert. -- Id de clef: 0xEF333C7E Fingerprint= 0C89 9588 23D5 DFB8 0DCD D349 3498 F05A EF33 3C7E ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] About deleting keys
Johan van Selst wrote: > >It doesn't matter if the information is verified. Users are asked for >their name and email address, which is considered personal data >(according to EU definitions) and keyservers are processing and storing >this data. Thereby, keyserver operators are subjected to the data >protection laws. The validity of the data is not relevant, neither is >the intention of the operators (commercial or otherwise). > Except that the keyserver does *not* make this request. That is done on a user's own machine. Everything else in this argument becomes a legal 'theory', which is a nice way of saying 'speculation'. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] About deleting keys
> How about a big, ugly label at the top of your search page: > > NOTICE: Access from the EU forbidden. > > Stupidity like that solves a (technically uninforcible) legal issue with > another (technically uniforcible and equally stupid) legal claim. I wanted to propose some similar. Each servers should accept client requests from at least 5000 km distance only. :-) Another idea: Service on port 11371 must be proxy-ed to a quite far server. So if somebody complains operator can say you have seen information from a key server at South-East Burma. And vica versa. Gabor -- This is just a brain storming, folks. Don't hit my head please. :) ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] About deleting keys
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Nov 04, 2013 at 10:14:53AM +0100, Johan van Selst wrote: >Petru Ghita wrote: >> But I don't really think that such a legal action is possible and >> assuming it was possible that it would have any degree of success. >[..] >> To sum it up: >> - there is by architecture no intent on verifing nor identifying the >> information stored on the SKS network nor the author of the data. >It doesn't matter if the information is verified. Users are asked for >their name and email address, which is considered personal data >(according to EU definitions) and keyservers are processing and storing >this data. Thereby, keyserver operators are subjected to the data >protection laws. The validity of the data is not relevant, neither is >the intention of the operators (commercial or otherwise). How about a big, ugly label at the top of your search page: NOTICE: Access from the EU forbidden. Stupidity like that solves a (technically uninforcible) legal issue with another (technically uniforcible and equally stupid) legal claim. - -- Regards... Todd We should not be building surveillance technology into standards. Law enforcement was not supposed to be easy. Where it is easy, it's called a police state. -- Jeff Schiller on NANOG Linux kernel 2.6.32-279.22.1.el6.x86_64 1 user, load average: 0.26, 0.11, 0.03 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAlJ3uGIACgkQIBT1264ScBX79gCeJjbzj/LFFLKkADuYaJOEu3fE /cAAnjt7moXQ7XgHbedM+UQKlbG+8YxR =3aVJ -END PGP SIGNATURE- ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] About deleting keys
On 11/04/2013 10:14 AM, Johan van Selst wrote: > Petru Ghita wrote: >> To sum it up: >> - there is by architecture no intent on verifing nor identifying the >> information stored on the SKS network nor the author of the data. > > It doesn't matter if the information is verified. Users are asked for Not only are they asked, they can provide whatever they like, possibly with the intention to harm ones reputation or cause damage to a person in some way. > their name and email address, which is considered personal data > (according to EU definitions) and keyservers are processing and storing > this data. Thereby, keyserver operators are subjected to the data > protection laws. The validity of the data is not relevant, neither is > the intention of the operators (commercial or otherwise). I think (I am no lawyer) the law (in the Netherlands) aims at organisations, not individual citizens (you can have a private address book). However, I don't want to find out in court. > If national or international data protection laws give users the right > to have their personal data removed from servers, then it should be > possible for local keyserver operators to comply with that law. > Preferably without terminating their service. I second that. > The privacy and data protection regulations are not the only thing to > worry about. If people put Nazi slogans or death threats into UID > fields, or put child pornography into JPEG attachments, then there may > be other laws that can force keyserver operators to remove keys. True. As SKS operator I am responsible for the data on my system. The fact I *choose* a software system (SKS) that is 'all or nothing' does not prevent a judge from telling me to remove particular data. If that means I have to remove all data, then that is my problem. > IMHO there is a clear demand for the option to remove certain keys - > or at least make them irretrievable locally. That some keyserver > operators are asking for the feature, should be reason enough to move on > to discussion of the technical aspects. We have a few questions that needs to be answered before going to technical solutions. These are some questions I can think of right now, please extend :-) Q1) is it sufficient to hide data for users of our service, while we keep full key data in our local database? Q1.1) if we hide data for the users of our service, do we hide all (like the key does not exist), do we strip uid's, but still return key material including key expiration, revocation, etc.? Q1.1.1) if we hide, but still provide some data, is it retrievable by key id only, or also as search result on name or e-mail? Q1.2) if we keep full key data in our database, are we allowed to actively send that data (push or pull) to our SKS peers? Q1.3) if we keep full key data in our database, do we allow that specific key to be updated by users of our service (i.e. from GnuPG, web interface)? Q2) if we remove data from our local database, do we remove all data of a key, or do we just strip some data (at least all uid's)? Q2.1) if we strip some data and keep some other, which data do we strip and which do we keep? Q2.2) If we keep some data in our local key server, but strip for example uid's, do we still update that key with other data (like expiration date of the key or a revoke certificate)? Q2.3) If we remove some or all data of a key, do we inform our peers during synchronisation? Q2.3.1) what to do when we receive a 'delete indication' from a peer, do we want to get a warning, do we want to delete the data also from our own server, do we want to delete that data only if we receive it from a peer we have marked as 'trusted' in our membership file, something else? Once we know what we want (ideally), the OCAML developers can see what is technically feasible short term, long term, 'at all' and which things are configurable (like only hiding, stripping uid's, totally removing a key, any mix per key, etc.) If the technical solution results in some servers providing data other servers do not, then we will have a follow-up discussion about which servers to include in the pool. But let's first get clear what we want as individual SKS operator. Arnold signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] About deleting keys
Petru Ghita wrote: > But I don't really think that such a legal action is possible and > assuming it was possible that it would have any degree of success. [..] > To sum it up: > - there is by architecture no intent on verifing nor identifying the > information stored on the SKS network nor the author of the data. It doesn't matter if the information is verified. Users are asked for their name and email address, which is considered personal data (according to EU definitions) and keyservers are processing and storing this data. Thereby, keyserver operators are subjected to the data protection laws. The validity of the data is not relevant, neither is the intention of the operators (commercial or otherwise). If national or international data protection laws give users the right to have their personal data removed from servers, then it should be possible for local keyserver operators to comply with that law. Preferably without terminating their service. The privacy and data protection regulations are not the only thing to worry about. If people put Nazi slogans or death threats into UID fields, or put child pornography into JPEG attachments, then there may be other laws that can force keyserver operators to remove keys. IMHO there is a clear demand for the option to remove certain keys - or at least make them irretrievable locally. That some keyserver operators are asking for the feature, should be reason enough to move on to discussion of the technical aspects. Regards, Johan pgpuf2AcyGXTJ.pgp Description: PGP signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
