Re: [Sks-devel] Keyservers and GDPR
Hi, On Mon, 2019-05-13 at 19:35 +0200, ilf wrote: > So far, I stand by last year's statement: > > > tl;dr: Keep calm and keep running keyservers. > Are you standing by your statement because you believe that processing that data is lawful or because you don't fear the consequences of a potentially unlawful processing of data? Cheers, Tobi ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Keyservers and GDPR
Tobias Mueller: So far, I stand by last year's statement: tl;dr: Keep calm and keep running keyservers. Are you standing by your statement because you believe that processing that data is lawful or because you don't fear the consequences of a potentially unlawful processing of data? I stand by my statement because of the reasons I explained last year. https://lists.gnupg.org/pipermail/gnupg-devel/2018-May/033708.html -- ilf If you upload your address book to "the cloud", I don't want to be in it. signature.asc Description: PGP signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Keyservers and GDPR
On 5/27/19 4:39 AM, Phil Pennock wrote: > hkps is limited because Kristian doesn't hand out certs to anyone who > shows up with a new keyserver and asks; he tends to do so with people > who've been around and part of the community, because of the fairly > obvious problems with assuming TLS is buying you anything when entirely > unknown-to-others folks run the servers. Kristian takes a lot of flak > for not giving people the power they want just because they ask for it. > > With the various problems of SKS today, I tentatively suggest that not > defaulting to the HKPS pool and choosing a different target for the > keys.gnupg.net CNAME might be beneficial. Adding some meta-info to this one. In addition to the above-mentioned concerns about new actors (in particular those not part of strong-set), it is also a question of capacity of the keyservers, so hkps pool is requiring load-balanced setup with minimum of 3 nodes on modern hardware (e.g a node today requires a minimum of 8 GiB of RAM to be responsive during merge of certain keys). The propagation time between the servers in the broader pool became quite big and servers dropping in-out sporadically due to merges. Now, this is somewhat better for the general pool since https://dev.gnupg.org/T4175 results in retry on failover for 5xx codes, but has caused a lot of problem reports in the past and not all distros ship this in stable versions. -- 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 Corruptissima re publica plurimæ leges The greater the degeneration of the republic, the more of its laws 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] Keyservers and GDPR
Hi all, sorry for stepping in as I am not working on this topic, but following the GDPA story for longer time I never read that we could simply prompt and agree with the terms of the authority hosting the information of the public key. The date and signature and probably reference to a version of the agreement can be added to the key and it won't be much of overhead. Isn't it more simple? Of course one should take care how the key servers exchange information in a secure way, but IMO on the surface it is a matter of an agreement between the person and the authority hosting the information of the public key. As Tobias Mueller was writing, it is all about handling personal information with care and not about fines. Of course all of this should stand in court as well, because there are many lawyers and companies that make money by legally blackmailing business entities that down not comply to GDPA. regards On Mon, May 27, 2019 at 11:02 AM ilf wrote: > Tobias Mueller: > >> So far, I stand by last year's statement: > >>> tl;dr: Keep calm and keep running keyservers. > > Are you standing by your statement because you believe that processing > > that data is lawful or because you don't fear the consequences of a > > potentially unlawful processing of data? > > I stand by my statement because of the reasons I explained last year. > https://lists.gnupg.org/pipermail/gnupg-devel/2018-May/033708.html > > -- > ilf > > If you upload your address book to "the cloud", I don't want to be in it. > ___ > Gnupg-devel mailing list > gnupg-de...@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] Search returns 500 MB blob
Hi all, We’re just running into a situation where we looked up a key for the email address j...@cix.ie. All keyservers we tried, including our very own one at pgp.circl.lu, returned a blob of 500 MB. Some key servers return a timeout after 30 seconds. The situation can also be tested with key ID 0x62cfc8f5, however, the returned blob is much smaller (23 MB). Has anyone else seen this or similar cases and investigated the root cause and what can be done to prevent systematically the exhaustion of resources? Thank you very much and with kind regards, Sascha Rommelfangen ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Keyservers and GDPR
On 27/05/2019 12:47, deloptes wrote: > it is a matter of an agreement between the person and the authority > hosting the information of the public key This is the problem though: there is no single identifiable authority (data controller in GDPR jargon) with whom to make such an agreement. Keyservers are distributed not just operationally and geographically, but also legally. Furthermore, it is not always the data owner who uploads it to the keyserver network, so neither party to the GDPR consent model need be present during the transaction, or need even exist. -- Andrew Gallagher 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] Keyservers and GDPR
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, 2019-05-27 at 14:28 +0100, Andrew Gallagher wrote: > On 27/05/2019 12:47, deloptes wrote: > > it is a matter of an agreement between the person and the authority > > hosting the information of the public key > > This is the problem though: there is no single identifiable authority > (data controller in GDPR jargon) with whom to make such an agreement. > Keyservers are distributed not just operationally and geographically, > but also legally. Furthermore, it is not always the data owner who > uploads it to the keyserver network, so neither party to the GDPR > consent model need be present during the transaction, or need even exist. Is that a binding legal opinion or a personal one? I ask, because in the USA (and presumably most western countries) there need not be a single identifiable entity necessary to bring suit. Doe subpoenas and multi-party lawsuits are real things. - -Jim P. -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEECPbAhaBWEfiXj/kxdRlcPb헹ᐔॳ꾩ꀀ⠤䇔数 fkX8ORAAmWG9BMllnQdBCaxZ7rbauKtcnM2WAuIZwyQCF0y1IfPMIuO4IjcfFBZj B/dvzDNdXZho/7ugDTSA7Ilل殫ᮼ펾쮪⿋䀩䨷�➿元뜿䕯 d/PJz두걢㠱뇞뀹꜄粈ᰴ䀪㎗䉝쿋�빤ᓘ뷲̆抆楹츁 TzcchQ6ZMYyoDxrSP6TCdN瀑䍮壾慵�䊖媓울⽆习⻎컲◪衴蕩 1YcFrgmJ0h8CD5dGoJAfxkWVyyLSDrAfKhkRhWGKIUKP7tCqQWgA4x9ojB濱 kGtXqeCtMNiA㟏籞㑈㖰瑻ぞ嚕⮯땑먣᪘떰䐒끕ꅐ BKtb/JFszauaMumDuMSMn33Tp8HIQmjxCG91bsIw1sl1TAEYjIMjRwRPHy9fwTys 67S7L1tzGsyL68YN1EZ9tEbUZgDtmji7NsHb5HLaei4E9Kn3k6j9FOilze1w/8D3 w4ioVbwl/EHlDCN4LYm8faVT3negT0nAqC4Tw3MlP6R5Wtu㸃⥺⣳辬 6YESgVmXf8B88KGF72BHcsIwZLmjyᜳ㤜믆磖ﰭ䘨ᵚ鶼⦝ᘧ푘 AdKYb2PpsVumbsdkdSP224vYAK2p/Qw0qcJGt6hTSqxuiJUsIJE= =xrBX -END PGP SIGNATURE- ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Keyservers and GDPR
On 27/05/2019 14:47, Jim Popovitch wrote: > On Mon, 2019-05-27 at 14:28 +0100, Andrew Gallagher wrote: >> On 27/05/2019 12:47, deloptes wrote: >>> it is a matter of an agreement between the person and the authority >>> hosting the information of the public key > >> This is the problem though: there is no single identifiable authority >> (data controller in GDPR jargon) with whom to make such an agreement. >> Keyservers are distributed not just operationally and geographically, >> but also legally. Furthermore, it is not always the data owner who >> uploads it to the keyserver network, so neither party to the GDPR >> consent model need be present during the transaction, or need even exist. > > Is that a binding legal opinion or a personal one? I ask, because in > the USA (and presumably most western countries) there need not be a > single identifiable entity necessary to bring suit. Doe subpoenas and > multi-party lawsuits are real things. Standard disclaimer applies: I am not a lawyer and nothing I say constitutes legal advice. I think you misunderstand me. The absence of a single data controller for the keyserver network is not a legal shield, quite the opposite. The GDPR "explicit consent" exemption does not readily apply to the keyserver network, because there is no practical way for an arbitrary keyserver to ensure that consent has been obtained for all the data it contains. But remember that explicit consent is only one of the permitted grounds for processing under GDPR (something that has been grossly overlooked in much of the public discourse), so this is not by itself definitive. -- Andrew Gallagher signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
