Re: Keyservers and GDPR

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
ilf
Reply | Threaded
Open this post in threaded view
|

Re: Keyservers and GDPR

ilf
FTR: I have not received a single reply. Happy GDPR day :)

ilf:
> Now I would like to know: Did any keyserver admin(s) receive any
> (serious) GDPR-related complaint? Or even an official complaint by a
> data protection authority? Or even a penalty like a fine?

--
ilf

If you upload your address book to "the cloud", I don't want to be in it.

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Keyservers and GDPR

Werner Koch
On Sat, 25 May 2019 14:53, [hidden email] said:

> ilf:
>> Now I would like to know: Did any keyserver admin(s) receive any
>> (serious) GDPR-related complaint? Or even an official complaint by a
>> data protection authority? Or even a penalty like a fine?

You mean from the left over 5 servers in the default hkps pool:

 pgpkeys.eu       51.38.91.189    AS16276 (UK)
 pgpkeys.uk       192.146.137.98  AS57672 (UK)
 pgpkeys.co.uk    192.146.137.99  AS57672 (UK)
 fks.pgpkeys.eu   46.4.246.179    AS24940 (DE, Hetzner)
 keys2.kfwebs.net 37.191.231.105  AS57963 (NO)

which according to rumours have only two or three different operators?


Salam-Shalom,

   Werner

--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Keyservers and GDPR

Phil Pennock-2
On 2019-05-26 at 10:43 +0200, Werner Koch wrote:

> On Sat, 25 May 2019 14:53, [hidden email] said:
> You mean from the left over 5 servers in the default hkps pool:
>
>  pgpkeys.eu       51.38.91.189    AS16276 (UK)
>  pgpkeys.uk       192.146.137.98  AS57672 (UK)
>  pgpkeys.co.uk    192.146.137.99  AS57672 (UK)
>  fks.pgpkeys.eu   46.4.246.179    AS24940 (DE, Hetzner)
>  keys2.kfwebs.net 37.191.231.105  AS57963 (NO)
>
> which according to rumours have only two or three different operators?

My old SKS membership file had both pgpkeys.co.uk and pgpkeys.eu
maintained by Daniel Austin; the off-by-one for pgpkeys.uk suggests
Daniel runs that one too.  That covers the first four.

kfwebs.net is Kristian Fiskerstrand, who runs the pool tracking system
and sks-keyservers.net.

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.

<https://sks-keyservers.net/overview-of-pools.php> has the criteria; I
suspect that >> subset.pool.sks-keyservers.net << is likely to be the
best choice for GnuPG; the meaning of "subset" changes over time,
picking newer servers, but for a while now that's been "updated SKS
software able to handle Curve25519 keys".

Spitballing crazy design now:

The only way to get back HKPS while still having diversity and yet still
some accountability is likely to be by requiring DNSSEC-signed
reverse-DNS which points to matching DNSSEC-signed forward DNS to prove
domain matching, and a trigger record in DNS indicating to use TLS; once
there's a forward-name which doesn't require central coordination, you
can verify normally and "anyone" can run a keyserver again.  With all
the pros and cons that entails.

GnuPG can pretty much define what it wants here.  Including changing the
URL scheme name if needed to avoid confusion.  TLSA records are
available for opportunistic TLS.  Effectively, "DANE for HKP with
work-arounds to handle the pool nature and bounce into a verifiable name
for arbitrary pool names".  Shove a TLSA record in reverse DNS to
indicate it's supported and you're good.  Hrm, probably don't strictly
need the reverse DNS to be DNSSEC-signed, as long as the
TLSA-or-other-marker is present and the forward DNS is still signed.

There's ways around it, but none of it will make folks who object to
DNSSEC happy.  Tough.

-Phil

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: Keyservers and GDPR

Tobias Mueller
In reply to this post by ilf
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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
ilf
Reply | Threaded
Open this post in threaded view
|

Re: Keyservers and GDPR

ilf
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.

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Keyservers and GDPR

Kristian Fiskerstrand-6
In reply to this post by Phil Pennock-2
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


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Keyservers and GDPR

deloptes
In reply to this post by ilf
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 <[hidden email]> 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
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: Keyservers and GDPR

Andrew Gallagher
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


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Keyservers and GDPR

Jim Popovitch-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, 2019-05-27 at 14:28 +-0100, Andrew Gallagher wrote:
+AD4 On 27/05/2019 12:47, deloptes wrote:
+AD4 +AD4 it is a matter of an agreement between the person and the authority
+AD4 +AD4 hosting the information of the public key
+AD4
+AD4 This is the problem though: there is no single identifiable authority
+AD4 (data controller in GDPR jargon) with whom to make such an agreement.
+AD4 Keyservers are distributed not just operationally and geographically,
+AD4 but also legally. Furthermore, it is not always the data owner who
+AD4 uploads it to the keyserver network, so neither party to the GDPR
+AD4 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+1fkUFAlzr6mgACgkQdRlcPb+1
fkX8ORAAmWG9BMllnQdBCaxZ7rbauKtcnM2WAuIZwyQCF0y1IfPMIuO4IjcfFBZj
B/dvzDNdXZho/7ugDTSA7Il+BkRrqxu8077Lqi/LQClKN9lqJ7/ytuLnUUO3P0Vv
d/PJz+tFCsYjgx4Q6x3rA5pwR8iBw0QCozl0Jdz8vfjL5kFNi98gMGYoZpec4Bku
TzcchQ6ZMYyoDxrSP6TCdN+cBFDblj+YXXZwkKWWpPGuC9GTmAuzs7yJeqIdIVp8
1YcFrgmJ0h8CD5dGoJAfxkWVyyLSDrAfKhkRhWGKIUKP7tCqQWgA4x9ojB+b/Feg
kGtXqeCtMNiA+8lw3z3xeNEg1sHR7MF5WlSuvtVG6IxqYtbBEErBVoVDi3O/JLSo
BKtb/JFszauaMumDuMSMn33Tp8HIQmjxCG91bsIw1sl1TAEYjIMjRwRPHy9fwTys
67S7L1tzGsyL68YN1EZ9tEbUZgDtmji7NsHb5HLaei4E9Kn3k6j9FOilze1w/8D3
w4ioVbwl/EHlDCN4LYm8faVT3negT0nAqC4Tw3MlP6R5Wtu+6Jc+Ayl6KPPnO4+s
6YESgVmXf8B88KGF72BHcsIwZLmjy+FzM5HLvG4xd41vwtRigdWp28KZ0WJ9RY42
AdKYb2PpsVumbsdkdSP224vYAK2p/Qw0qcJGt6hTSqxuiJUsIJE=
=xrBX
-----END PGP SIGNATURE-----



_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel
Reply | Threaded
Open this post in threaded view
|

Re: Keyservers and GDPR

Andrew Gallagher
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


_______________________________________________
Sks-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/sks-devel

signature.asc (849 bytes) Download Attachment