Re: [Sks-devel] Keyservers and GDPR

[Dirk-Willem van Gulik]

On 29 May 2019, at 09:07, Werner Koch  wrote:

> Which would support my point to redesign the keyservers to
> 
> - Inhibit searches by user id.

What is the reasoning behind this (as signing keys just are on the uploaded key 
with a keyid — so we are talking about the key its own data) ?

And pair this if needed with a submission protocol that insists on having the 
private key.

That would also openup, from a GDPR perspective, allowing the signing key ids 
back in.

Dw.


___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Keyservers and GDPR

[Werner Koch]

On Mon, 27 May 2019 13:30, kristian.fiskerstr...@sumptuouscapital.com
said:

> 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

Which would support my point to redesign the keyservers to

 - Inhibit searches by user id.
 
 - Drop all key signatures except for self-signatures and designated
   revocations.

The first change will make Gnupg --search-keys useless and that command
could thus be changed to do a --locate-key with disabled local keyring.

The second requires that key-signatures must be send to the key owner
directly, which is anyway what most people do.  And obviously the key
owner needs to distribute them by other means than the keyservers to
make the few WoT users happy.

Right, this requires that self-signatures are verified on upload.


Salam-Shalom,

   Werner

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


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

[Werner Koch]

On Sun, 26 May 2019 22:39, gnupg-de...@spodhuis.org said:

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

FWIW, keys.gnupg.net is since gnupg 2.2.7 not a CNAME name but aliased
by dirmngr in this way:

  hkps://keys.gnupg.net   -> hkps://hkps.pool.sks-keyservers.net
  https://keys.gnupg.net  -> https://hkps.pool.sks-keyservers.net
  hkp://keys.gnupg.net-> hkp://hkps.pool.sks-keyservers.net
  http://keys.gnupg.net   -> http://hkps.pool.sks-keyservers.net
  hkps://http-keys.gnupg.net  -> hkps://ha.pool.sks-keyservers.net
  https://http-keys.gnupg.net -> https://ha.pool.sks-keyservers.net
  hkp://http-keys.gnupg.net   -> hkp://ha.pool.sks-keyservers.net
  http://http-keys.gnupg.net  -> http://ha.pool.sks-keyservers.net

  keys.gnupg.net  -> hkps://hkps.pool.sks-keyservers.net
  http-keys.gnupg.net -> hkps://ha.pool.sks-keyservers.net

this was needed to void problems with server name matching.  Thus we
can't change that easily.  Anyway, it is suggested tha the default
keyserver is used which is  hkps://hkps.pool.sks-keyservers.net  To
change this the keyserver option in dirmngr.conf needs to be used.

> suspect that >> subset.pool.sks-keyservers.net << is likely to be the
> best choice for GnuPG; the meaning of "subset" changes over time,

I am pretty sure that changing to this as the default will raise a lot
of concerns from the folks who want to elimiated the use of the string
"http://;.



Shalom-Salam,

   Werner

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


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

[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



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

[Jim Popovitch]

-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

[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



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

[deloptes]

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

Re: [Sks-devel] Keyservers and GDPR

[Kristian Fiskerstrand]

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

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


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

[Tobias Mueller]

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

[Phil Pennock]

On 2019-05-26 at 10:43 +0200, Werner Koch wrote:
> On Sat, 25 May 2019 14:53, i...@zeromail.org said:
> You mean from the left over 5 servers in the default hkps pool:
> 
>  pgpkeys.eu   51.38.91.189AS16276 (UK)
>  pgpkeys.uk   192.146.137.98  AS57672 (UK)
>  pgpkeys.co.uk192.146.137.99  AS57672 (UK)
>  fks.pgpkeys.eu   46.4.246.179AS24940 (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.

 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
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Keyservers and GDPR

[Werner Koch]

On Sat, 25 May 2019 14:53, i...@zeromail.org 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.189AS16276 (UK)
 pgpkeys.uk   192.146.137.98  AS57672 (UK)
 pgpkeys.co.uk192.146.137.99  AS57672 (UK)
 fks.pgpkeys.eu   46.4.246.179AS24940 (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.


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

[Georg Faerber]

Hi,

On 19-05-13 23:23:45, Tobias Frei wrote:
> https://lists.nongnu.org/archive/html/sks-devel/2019-02/msg00070.html

I'm not completely sure what you want to say by posting this link, but,
right, that is one example of such a request, answered by Kristian, no
fine involved, AFAIK.

There were other mails on this list describing such requests, but, if
asked for details, people didn't shared any.

I agree with ilf:

> tl;dr: Keep calm and keep running keyservers.

Cheers,
Georg


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

[Tobias Frei]

Hi ilf,

https://lists.nongnu.org/archive/html/sks-devel/2019-02/msg00070.html

Best regards
Tobias Frei
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Keyservers and GDPR

[ilf]

Almost one year ago, there was a big debate about the GDPR and 
keyservers. 

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?


I assume not, at least for the latter two.

The fines by German DPAs have been rather low: 
https://www.welt.de/finanzen/article193326155/DSGVO-Verstoesse-Bundeslaender-ziehen-Bussgeld-Bilanz.html


So far, I stand by last year's statement:


tl;dr: Keep calm and keep running keyservers.


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

[Patrick Brunschwig]

On 22.05.18 21:44, Vincent Breitmoser wrote:
[...]
> My personal conclusion is that keyservers that support user id packets are,
> quite simply, incompatible with GDPR law. Has anyone else thought about this?
> It's fairly unlikely that there will be actual consequences since keyservers
> aren't widely used, but running a keyserver on this assumption is hardly
> reassuring.

There are actually two different types of keyservers, which should be
clearly distinguished.

1. the pool of SKS keyservers: as anyone can upload anybody's key, and
as it does not allow to delete keys, it's IMHO by not compatible with GDPR.

2. other types of keyservers like the run by Mailvelope (and possibly
others that I don't know of), that verify the keys they receive and
allow to delete keys, are compatible with GDPR, or can be made
compatible easily.

-Patrick

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] Keyservers and GDPR

[Bernhard Reiter]

Hi Vincent,

Am Dienstag 22 Mai 2018 21:44:09 schrieb Vincent Breitmoser:
> My personal conclusion is that keyservers that support user id packets are,
> quite simply, incompatible with GDPR law. Has anyone else thought about
> this?

thinking about earlier data privacy laws (which were quite similiar to GDPR in 
many respects) and pubkey servers got me to no clear conclusion.

> For OpenKeychain, we plan to move uploading of key material a bit farther
> out of the way and do a better job at informing the user what's going to
> happen.

If our goal is to automate the common case in an end-to-end crypto
mail communication, then asking the user a data privacy agreement question
is a stumbling block. I would degrate the user experience a lot.

Note that if you use WKD with your email provider and just the email address
in the key id (as supported by a policy option), there is no additional 
personal data saved nor communicated. The email provider already has your 
email address and the person asking via WKD also. In addition serving of the
public key on behalf of ther user could be added to the terms of service
of the email provider. Overal I think WKD is doing quite well on the data 
privacy side and will allow a good user experience by not asking each time to 
publish a new pubkey for oneself.

Best Regards,
Bernhard

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


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] Keyservers and GDPR

[Kristian Fiskerstrand]

On 05/23/2018 11:27 AM, ilf wrote:
> tl;dr: Keep calm and keep running keyservers.
> 
> Vincent Breitmoser:
>> (cross-posting on all the cool pgp lists)
> 
> (I wonder, if this really needs to be an all the four lists. I think
> sks-devel@ might be the most appropriate. Having said that, I'm only
> replying to gnupg-devel@ because I'm not subscribed to sks-devel@. Feel
> free to relay my message.)

As I think this has a valuable viewpoint I'm posting it to sks-devel.
And yes, this is mostly in line with my own thinking, I don't expect the
need for radical changes unless we see actual attempts to go after the
infrastructure.

> 
>> My personal conclusion is that keyservers that support user id packets
>> are, quite simply, incompatible with GDPR law.
> 
> There is a ton of FUD about the GDPR out there right now. Most of it   
> frivolous. (Actually, a lot of it is deliberate fearmongering by people
> who happen to sell legal advice on the GDPR.)
> 
> First of all, the GDPR is not completely new. All EU member states
> already have data protection laws, some - like Germany - already very 
> strong ones. The concepts (PII, responsibilities, technological and
> organisational measures, information and documentation obligations) have
> already been in place with the old Data Protection Directive from 1995,
> which the GDPR is updating. I admit that the GDPR can be read and
> interpreted in a fatalist way. But most people leaning that way seem to
> not have read the older laws.
> 
> Laws are not set in stone. Laws include leeways, deliberate or
> unintended. Laws do not depend on their interpretation by laypeople.
> There is a huge dedicated system for its interpretation, conflict
> resolve, judgement and enforcement.
> 
> In the case of the GDPR, the very first step of that system are National
> Data Protection Authorities (DPA). They have the power - and the
> responsibility - to investigate possible violations of the GDPR. They
> have been understaffed for years, in many countries dangerously so. They
> are getting a lot more powers and responsibilities with the GDPR, but
> their resources are growing way slower than their tasks. They are simply
> understaffed and overworked. So from all the possible GDPR violations
> they will be notified about, they will work off the biggest and most
> obvious ones first. Their focus will be on the Facebooks - and not on
> small nerd projects or personal websites. They have the power to say "we
> don't care about this weird thing called keyserver" - and the probably
> will.
> 
> Now even if someone found data protection law infringements with a
> keyserver, filed a specific and well-worded legal complaint with a DPA,
> and a DPA found the resources to look into it, and the DPA found some
> violation of the GDPR (four big IFs!) - the DPAs will not go around and
> issue sanctions and fine people. First of all, their job is not to
> generate revenues by fines. Their job is to enforce data protection law.
> If a DPA did find an issue with a keyserver - or the very concept - they
> would reach out and talk to the people running the servers. They would
> hear their perspective, learn more about the very concept - and try to
> work out a viable solution to provide the service without possible data
> protection infringements. This is their job and their goal.
> 
> The most feared sanction of some undefined GDPR violation is a fine. As
> I layed out, DPAs don't want to issue fines, they want to stop privacy
> violations. And they will not blindly issue a fine without talking to
> you first. That being said, they obviously do have the power to issue
> fines. After due process. However, this power is also not new, it has
> also existed in many countries. And DPAs don't run around and fine
> people left and right (you would have heard about that), they exercise
> their power in a balanced way. And fines are always in relation to the
> economic and personal circumstances of the - then guilty and obstinate -
> data protection violators. I guess most keyservers are run by 
> non-profit individuals or institutions. Even if a company runs a
> keyserver, it doesn't make money with that service. Therefore, I think
> the chance of *any* fine is negligible - and the chance of an
> unreasonably high fine is almost zero. And if it ever came to this, the
> community and public alarmed by public outcry would probably donate more
> than the fine issued.
> 
> To sum up: Keep calm and keep running keyservers. You'll be fine.
> 
> More elaboration in German:
> https://netzpolitik.org/2018/bussgelder-bei-datenschutzverstoessen-angst-vor-einem-phantom/
> 
> 
> Disclaimer: IANAL. This is not legal advice.
> 
> 
> 
> ___
> Gnupg-devel mailing list
> gnupg-de...@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
> 


-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Re: [Sks-devel] Keyservers and GDPR

[Niels Dettenbach (Syndicat IT & Internet)]

Am 22. Mai 2018 21:44:09 MESZ schrieb Vincent Breitmoser :
>Now, since the PII that is uploaded is not used to fulfill contractual
>obligations

I'm not a lawyer, but i see this vice versa. 

Users upload their keys for the purpose of their usage in the "web of trust" 
and expect their availability (storage, processing)there for this. 

A contract with the server owner/admin IS emerged with the transfer of the data 
in the conventional keyserver protocol without any further "written" contract.

Extended, written explicite order is required if the keyserver (their owner) 
want to use that data for other purposes, not covered by the specs.

This is my view. But clearifying this needs a good las expert with a good 
understanding in the specs and the whole process.


just my two cents.

Niels.

-- 
Niels Dettenbach
Syndicat IT & Internet
http://www.Syndicat.com

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Sks-devel] Keyservers and GDPR

[Vincent Breitmoser]

Sigh, I just now noticed that I wasn't actually subscribed to sks-devel anymore,
I thought I was.  I humbly apologize for the noise, and will go read the
relevant threads now :)

 - V


___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

[Sks-devel] Keyservers and GDPR

[Vincent Breitmoser]

Hey there,

(cross-posting on all the cool pgp lists)

so Dominik and I have been thinking a bit about how GDPR might affect
OpenKeychain, and its interoperability with public keyservers.  Turns out this
is a hard question - in the end we couldn't answer whether publishing a tool
that offers keyserver interoperability really made us a "data controller"?

But let's start with keyservers first: "Processing" of data in the GDPR sense
includes storage and distribution. Names and email addresses are personally
identifiable information (PII). This makes the provider of a keyserver a data
processor in the sense of the GDPR.

Now, since the PII that is uploaded is not used to fulfill contractual
obligations, keyservers actually need informed consent from the user about what
is going to happen with that data.  It's unclear how such consent might look
like given the API interface.  But what's worse, in the current implementation
of SKS and the public keyserver pool, it is impossible by design to remove
a user's data once it is published.  This conflicts with the "right to be
forgotten".

My personal conclusion is that keyservers that support user id packets are,
quite simply, incompatible with GDPR law. Has anyone else thought about this?
It's fairly unlikely that there will be actual consequences since keyservers
aren't widely used, but running a keyserver on this assumption is hardly
reassuring.

From the view of an app, the GDPR requires "privacy by design" and "privacy by
default". This conflicts with a workflow that asks the user for their email
address and name, and then irremovably uploads this information to a public
listing. On the other hand, it can be argued that this is a tool that only does
what the user asks it to do, the decision and responsibility lies with the user.
Looking at some extreme cases: a Browser surely doesn't take responsibility for
what the user inputs on websites. But a Twitter client does take responsibility
for informing the user when they publish their location in their tweets.

For OpenKeychain, we plan to move uploading of key material a bit farther out of
the way and do a better job at informing the user what's going to happen. But
that's a stopgap measure, since the user can't simply be asked to waive their
rights. Hopefully we can soon move away from keyservers for key discovery or
distribution.

Thoughts?

 - V

PS: randomly signing this message /o/



signature.asc
Description: PGP signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel