Re: [Sks-devel] GDPR (equine corpse) (WAS: Re: The pool is shrinking)

[brent s.]

On 8/20/19 6:05 AM, Tobias Mueller wrote:
(SNIP)
>> This means not only are keydumps allowed for research (§2), but the
>> SKS in general (ESPECIALLY US servers and operators, which I'll get to
>> in a moment) is exempt - we provide "...archiving purposes in the
>> public interest" (§3). Frankly put, we make GPG *work*. GPG is a
>> *very* valuable public tool - zero-trust-model public cryptography is
>> impossible without the Web-of-Trust. Ergo, exempt. It's that simple.
> No. And no, it's not.
> You are reading this wrongly.
> §89 says that member states *can* enact laws which exempt controllers
> from their duties with respect to erasure or correction *iff* the
> legitimate ground is the public interest (which itself is highly
> questionable).
> You don't gain anything from this §89 GDPR if member states do not
> create a law. And even then you wouldn't be fully exempt (as you
> suggest), but rather have an easier life as a controller.
> If we require member states to enact laws, then we're better off
> pursuing laws based on §85 GDPR, but that'd go too far for this
> discussion here.  I'm happy to have this elsewhere.
> 
> Cheers,
>   Tobi
> 


Sure; while §17(d) makes allowance via §89, it would - for example -
require a UK operator to associate with the Nat'l Registry of
Archives[0] to get the furthest extent of legal coverage (under §89
*specifically*).

However, the GDPR also makes exemption for TEU, Title V (2)(b) as well
without requiring a member state to make allowance. So an EU operator
could, should they fear GDPR repercussions, either 1.) pursue enacted
legislation/established archival status within their member state to
come under protection of §89 OR 2.) appeal to be a provider a service
under TEU Title V.

Worth noting that Article 23 of GDPR also allows derogations for public
security as well.

HOWEVER, also note that *processing* of keys would fall under Article 6
(1)(f) (legitimate interest being defined via Recital 49) which requires
no explicit derogation of member states. Being that the public key is
necessary for the operation of the processing of keys in the duties of
"...preventing .. malicious code distribution"(Recital 49)(though GPG
itself serves a much broader use to protect the rights and freedoms of
EU citizens as well, which are widely covered throughout the GDPR) -
such as GPG signatures on release tarballs, for instance - the erasure
situation can be considered covered as well.

GPG *also* enables compliance with Article 32(1)(a) and (b).

Of course, this is all untested because to my knowledge an EU keyserver
operator hasn't been challenged and it hasn't been brought to an EU
court yet, so there's no established example. But the case is quite
strong for the keyserver operator, I'd say.



[0] https://www.nationalarchives.gov.uk/

-- 
brent saner
https://square-r00t.net/
GPG info: https://square-r00t.net/gpg-info



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] GDPR (equine corpse) (WAS: Re: The pool is shrinking)

[Tobias Mueller]

Hi,

On Fri, 2019-08-16 at 19:28 -0400, brent s. wrote:
> SO for starters, please keep this off the "pool is shrinking" thread.
> I'd like to see that thread relevant to resolving resiliency issues of
> the SKS network, given that's the actual purpose behind starting that
> thread. GDPR is off-topic to that thread and, quite frankly, it's
> getting *extremely* annoying seeing GDPR bickering in a thread I'm
> trying to follow for technical solutions to an actual technical
> problem.
I understand you and I think many of us are in the same boat.
Yet, let me quickly refute a statement of yours before it becomes
folklore.


> Take special notice of Article 89[3].
> 
> This means not only are keydumps allowed for research (§2), but the
> SKS in general (ESPECIALLY US servers and operators, which I'll get to
> in a moment) is exempt - we provide "...archiving purposes in the
> public interest" (§3). Frankly put, we make GPG *work*. GPG is a
> *very* valuable public tool - zero-trust-model public cryptography is
> impossible without the Web-of-Trust. Ergo, exempt. It's that simple.
No. And no, it's not.
You are reading this wrongly.
§89 says that member states *can* enact laws which exempt controllers
from their duties with respect to erasure or correction *iff* the
legitimate ground is the public interest (which itself is highly
questionable).
You don't gain anything from this §89 GDPR if member states do not
create a law. And even then you wouldn't be fully exempt (as you
suggest), but rather have an easier life as a controller.
If we require member states to enact laws, then we're better off
pursuing laws based on §85 GDPR, but that'd go too far for this
discussion here.  I'm happy to have this elsewhere.

Cheers,
  Tobi


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

Re: [Sks-devel] GDPR (equine corpse)

[Stefan Claas]

Todd Fleisher wrote:
 
> Thanks for providing these links, I'll have to check them out. I haven't used
> an anonymous remailer since anon.penet.fi went dark over two decades ago 
> 
> https://en.m.wikipedia.org/wiki/Penet_remailer

You're welcome! Yes, good old penet. ;-)

Regards
Stefan

-- 
box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56
GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD)

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

Re: [Sks-devel] GDPR (equine corpse)

[Todd Fleisher]

> On Aug 17, 2019, at 18:00, Stefan Claas  wrote:
> 
> Todd Fleisher wrote:
> 
>>> On Aug 17, 2019, at 8:46 AM, Stefan Claas >> > wrote:
>>> 
>>> Anonymity is a very important point when one likes to communicate securely
>>> and anonymously!
>>> 
>>> For that purpose Anonymous Remailers with a Nym account are in service
>>> for many years. It requires on the users side that he / she is familiar
>>> with GPG, to create a Nym account.
>>> 
>>> http://is-not-my.name/ 
>> 
>> This could be considered a bit pedantic … but I would consider a website
>> serving content over unencrypted http and using an invalid SSL certificate
>> for serving https traffic to be neither anonymous nor secure:
>> https://i.imgur.com/drVX1EX.jpg 
> 
> Well, it is only a very old information page. The usage of those Nyms is 
> secure,
> in combination with Mixmaster.
> 
> People not trusting such a service may check out the source code and set-up
> their own Nym Server.
> 
> https://github.com/crooks/nymserv
> 
> There are two more Nym servers available, which I forgot to mention:
> 
> https://remailer.paranoici.org/nym.php
> 
> https://thinhose.net/
> 
> Regards
> Stefan

Thanks for providing these links, I'll have to check them out. I haven't used 
an anonymous remailer since anon.penet.fi went dark over two decades ago 

https://en.m.wikipedia.org/wiki/Penet_remailer

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

Re: [Sks-devel] GDPR (equine corpse)

[Stefan Claas]

Todd Fleisher wrote:

> > On Aug 17, 2019, at 8:46 AM, Stefan Claas  > > wrote:
> > 
> > Anonymity is a very important point when one likes to communicate securely
> > and anonymously!
> > 
> > For that purpose Anonymous Remailers with a Nym account are in service
> > for many years. It requires on the users side that he / she is familiar
> > with GPG, to create a Nym account.
> > 
> > http://is-not-my.name/ 
> 
> This could be considered a bit pedantic … but I would consider a website
> serving content over unencrypted http and using an invalid SSL certificate
> for serving https traffic to be neither anonymous nor secure:
> https://i.imgur.com/drVX1EX.jpg 

Well, it is only a very old information page. The usage of those Nyms is secure,
in combination with Mixmaster.

People not trusting such a service may check out the source code and set-up
their own Nym Server.

https://github.com/crooks/nymserv

There are two more Nym servers available, which I forgot to mention:

https://remailer.paranoici.org/nym.php

https://thinhose.net/

Regards
Stefan

-- 
box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56
GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD)

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

Re: [Sks-devel] GDPR (equine corpse)

[brent s.]

On 8/17/19 4:44 PM, Tobias Frei wrote:
> 
> 
> On Aug 17, 2019 19:11, Stefan Claas  wrote:
> 
> Interesting! If understood correctly the advantage then would be no
> changes
> 
> in the SKS code and simply using a front-end key parser, with a
> defined rule
> set, right?
> 
> And false positives. And ineffectiveness against new attacks. And
> vulnerability through peering unless everyone runs the same frontend
> parser, which, if distributed together with SKS, is basically an
> amendment (I would say "change"?) to the SKS code. Interesting mainly
> for the reasons it fails for.
> 
> Besr regards 
> Tobias Frei
> 


Yep, +1 - this is what I meant in part by "which is always going to be
faulty to some degree and just ends up as a cat-and-mouse game."

Heuristic analysis is *really* hard to do... well, effectively at all.
It's more of a fun thought experiment than anything. ;) As Tobias points
out above, you're now no longer just depending on the same RECON
protocol being supported between keyservers, but they also have to share
the exact same heuristic ruleset/filters, engine, etc. - otherwise you
end up with an issue with keyservers endlessly disagreeing on which keys
to sync. Which is a different form of one of the current issues in
peering (there's a couple HUGE keys that churn CPU and tend to fail out
when trying to sync).

I think we all agree that the SKS code could use some modernization[0]
and modifications, Stefan; it's just that nobody has any good ideas for
*how* to fix these problems without creating *more* problems in such a
way that won't totally break the purpose and design of decentralized
public cryptography/identity verification/etc.


[0] I don't care what language it's written in, but it won't
compile/process in anything newer than OCAML/CAMLP 4.05 in my attempts.

-- 
brent saner
https://square-r00t.net/
GPG info: https://square-r00t.net/gpg-info



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] GDPR (equine corpse)

[Todd Fleisher]

> On Aug 17, 2019, at 8:46 AM, Stefan Claas  > wrote:
> 
> Anonymity is a very important point when one likes to communicate securely
> and anonymously!
> 
> For that purpose Anonymous Remailers with a Nym account are in service
> for many years. It requires on the users side that he / she is familiar
> with GPG, to create a Nym account.
> 
> http://is-not-my.name/ 

This could be considered a bit pedantic … but I would consider a website 
serving content over unencrypted http and using an invalid SSL certificate for 
serving https traffic to be neither anonymous nor secure: 
https://i.imgur.com/drVX1EX.jpg 

-T

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

Re: [Sks-devel] GDPR (equine corpse)

[Tobias Frei]

On Aug 17, 2019 19:11, Stefan Claas  wrote:Interesting! If understood correctly the advantage then would be no changes
in the SKS code and simply using a front-end key parser, with a defined rule
set, right?
And false positives. And ineffectiveness against new attacks. And vulnerability through peering unless everyone runs the same frontend parser, which, if distributed together with SKS, is basically an amendment (I would say "change"?) to the SKS code. Interesting mainly for the reasons it fails for.Besr regards Tobias Frei___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel

Re: [Sks-devel] GDPR (equine corpse)

[Stefan Claas]

brent s. wrote:

> On 8/17/19 11:46 AM, Stefan Claas wrote:

> > The other points you have mentioned, like the signer cannot upload a key,
> > well that's true but I wonder how you guys like then to solve the problem
> > with uploading flooded key material to the key servers. I think you can
> > not have all options, but I am all ears.
> > 
> > Regards
> > Stefan
> > 
> 
> Hence the original discussion, yes. The only way to do it that I can
> think if is one (or both) of:
> 
> - blacklisting keys, which makes the server peering *incredibly* more
> complex (and, it can be made the case for, impossible) - if you were
> following this mailing list for a while, you'd have seen us discuss this
> very issue many, many times. For something like 8 months now. Check the
> archives.

Will do.

> - heuristic analysis, which is always going to be faulty to some degree
> and just ends up as a cat-and-mouse game.

Interesting! If understood correctly the advantage then would be no changes
in the SKS code and simply using a front-end key parser, with a defined rule
set, right?

Regards
Stefan 

-- 
box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56
GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD)

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

Re: [Sks-devel] GDPR (equine corpse)

[brent s.]

On 8/17/19 11:46 AM, Stefan Claas wrote:
> Anonymity is a very important point when one likes to communicate securely
> and anonymously!
> 
> For that purpose Anonymous Remailers with a Nym account are in service
> for many years. It requires on the users side that he / she is familiar
> with GPG, to create a Nym account.
> 
> http://is-not-my.name/
> 
> The Remailer Software itself (Mixmaster) is included in Linux distributions.
> Windows users have Mixmaster clients too. One only needs a free Usenet
> account to pick up messages from the News Group alt.anonymous.messages.

Except no, because now you aren't talking about email anymore, you're
adding an *additional* layer of complexity. Additionally, I'm talking
about a key with *no email address whatsoever*. Again, this is an OPSEC
issue. Your proposal still requires an additional external piece of PII,
as "anonymous" as it may be.

> 
> Then there are probably still free anonymous Tor email accounts available.
> 
> Another option would be to set-up an email to Bitmessage Gateway (like
> Mailchuck) so that GPG users can submit their keys from within the Bitmessage
> client to the key server via the email Gateway.
> 
> https://github.com/V07D/bitmessage-email-gateway

Again, see above. This is no longer email you're talking about. Further,
it still requires *a valid PII to validate the key reception*. Further
still, it creates an additional dependence on a third-party provider. No
bueno.

> 
> The other points you have mentioned, like the signer cannot upload a key,
> well that's true but I wonder how you guys like then to solve the problem
> with uploading flooded key material to the key servers. I think you can
> not have all options, but I am all ears.
> 
> Regards
> Stefan
> 

Hence the original discussion, yes. The only way to do it that I can
think if is one (or both) of:

- blacklisting keys, which makes the server peering *incredibly* more
complex (and, it can be made the case for, impossible) - if you were
following this mailing list for a while, you'd have seen us discuss this
very issue many, many times. For something like 8 months now. Check the
archives.

- heuristic analysis, which is always going to be faulty to some degree
and just ends up as a cat-and-mouse game.



-- 
brent saner
https://square-r00t.net/
GPG info: https://square-r00t.net/gpg-info



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] GDPR (equine corpse)

[Stefan Claas]

brent s. wrote:

> I'm going to anticipate what you're suggesting this solves - that only
> key owners can upload their own key by ensuring the sender matches one
> of the key's identities. There's flaws with that:
> 
> 1.) You've now broken the ability to upload keys with no real
> identifiable information (i.e. no real email address), thus *forcing*
> users of a keyserver to provide personal identifiable information. This
> breaks anonymity.

Anonymity is a very important point when one likes to communicate securely
and anonymously!

For that purpose Anonymous Remailers with a Nym account are in service
for many years. It requires on the users side that he / she is familiar
with GPG, to create a Nym account.

http://is-not-my.name/

The Remailer Software itself (Mixmaster) is included in Linux distributions.
Windows users have Mixmaster clients too. One only needs a free Usenet
account to pick up messages from the News Group alt.anonymous.messages.

Then there are probably still free anonymous Tor email accounts available.

Another option would be to set-up an email to Bitmessage Gateway (like
Mailchuck) so that GPG users can submit their keys from within the Bitmessage
client to the key server via the email Gateway.

https://github.com/V07D/bitmessage-email-gateway

The other points you have mentioned, like the signer cannot upload a key,
well that's true but I wonder how you guys like then to solve the problem
with uploading flooded key material to the key servers. I think you can
not have all options, but I am all ears.

Regards
Stefan
-- 
box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56
GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD)

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

Re: [Sks-devel] GDPR (equine corpse) (WAS: Re: The pool is shrinking)

[brent s.]

On 8/17/19 8:08 AM, Stefan Claas wrote:
> brent s. wrote:
> 
>> 4.) *Real* identifiable personal information is by *no means* a
>> requirement for the creation of a key, nor making it available on a
>> keyserver. Granted, you're going to face some challenges at a
>> traditional keysigning party, but simply
> 
> How about email submission like we had in the '90s and getting
> rid of --send-keys or the WWW submit button?
> 
> I believe installing postfix or exim etc. can be easily done
> by operators and a person could quickly write a script which
> then pipes the received keys to the database.
> 
> Regards
> Stefan
> 

I'm going to anticipate what you're suggesting this solves - that only
key owners can upload their own key by ensuring the sender matches one
of the key's identities. There's flaws with that:

1.) You've now broken the ability to upload keys with no real
identifiable information (i.e. no real email address), thus *forcing*
users of a keyserver to provide personal identifiable information. This
breaks anonymity.

2.) Key signatures (key signatures are called "certifications" in the
design documentation) are now broken since signers cannot upload key
signatures, breaking the Web-of-Trust. When you upload a certification,
you are uploading the updated public key. You can strip certifications
from a key, you can't strip a key from certifications. See RFC 4880[0] §
11.1[1]. Actually, read the whole RFC. It's insightful and gives a lot
of knowledge into the output from "gpg --list-packets".

   a.) inb4 "But why can't the signer just send the updated key to the
key owner, and the owner can upload it?"

   See #1. While I have this feature in a keysigning tool I wrote[2]
(which is currently incredibly messy and needs a major refactoring, I
know), it still only works if the signed key has a valid email address
and it furthermore would still require a valid email address by the
owner to upload to a keyserver if email addresses were received by mail
(even if the signed key was passed to the owner via a previously agreed
upon non-email/alternate email communication).

   b.) Remember, key signatures are intended for public consumption -
it's how trust is arbitrated via the Web-of-Trust so you can apply trust
levels to keys that you yourself have not been able to directly verify
with the owner. The Web-of-Trust is not flat, it's by degrees (e.g. "Bob
signed Alice's key, and I trust Bob's veracity in checking validity of
key ownership completely because I know how thorough he is, so I can
apply a medium level of trust to this key locally" - which also, thanks
to the Web-of-Trust, allows others to trust Alice AND Bob's key because
you trust Bob.[3]

   c.) Similarly, this also requires the *signer* to expose a real email
address to the owner of the key they signed at the LEAST, breaking the
*signer's* option for anonymity (and requires that at LEAST the key
owner know beforehand which communication identity the signed key is
coming from).

3.) This also depends further on an MTA being run on keyservers (or at
the least in tandem with them by the same operator). Running a mail
server is not a demand to be made lightly on anyone, given that mail is
a quagmire that the inexperienced should not approach lightly. There's a
reason that many places have a single operator designated entirely to
the maintenance of their email.



[0] https://tools.ietf.org/html/rfc4880
[1] https://tools.ietf.org/html/rfc4880#section-11.1
[2] https://git.square-r00t.net/OpTools/tree/gpg/kant
[3] https://www.gnupg.org/gph/en/manual/x547.html
(pay close attention to paragraphs 3 and 4)

-- 
brent saner
https://square-r00t.net/
GPG info: https://square-r00t.net/gpg-info



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] GDPR (equine corpse) (WAS: Re: The pool is shrinking)

[Stefan Claas]

brent s. wrote:

> 4.) *Real* identifiable personal information is by *no means* a
> requirement for the creation of a key, nor making it available on a
> keyserver. Granted, you're going to face some challenges at a
> traditional keysigning party, but simply

How about email submission like we had in the '90s and getting
rid of --send-keys or the WWW submit button?

I believe installing postfix or exim etc. can be easily done
by operators and a person could quickly write a script which
then pipes the received keys to the database.

Regards
Stefan

-- 
box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56
GPG: C93E252DFB3B4DB7EAEB846AD8D464B35E12AB77 (avail. on Hagrid, WKD)

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

Re: [Sks-devel] GDPR (equine corpse) (WAS: Re: The pool is shrinking)

[Robert J. Hansen]

> IANAL, but only one person in this discussion has mentioned that they
> HAVE consulted one that specializes in data privacy - who confirms that
> specifically, for a US keyserver operator operating a US keyserver, GDPR
> has *absolutely no bearing* even if we *weren't* exempt.

Minor nit: that was the advice I received, tailored to my specific
situation.  Other US-based operators in different situations may have
different legal exposure.  The more connections a US operator has to the
EU, the greater the EU's ability to apply leverage.



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

[Sks-devel] GDPR (equine corpse) (WAS: Re: The pool is shrinking)

[brent s.]

SO for starters, please keep this off the "pool is shrinking" thread.
I'd like to see that thread relevant to resolving resiliency issues of
the SKS network, given that's the actual purpose behind starting that
thread. GDPR is off-topic to that thread and, quite frankly, it's
getting *extremely* annoying seeing GDPR bickering in a thread I'm
trying to follow for technical solutions to an actual technical problem.

There are countless threads hrmming and hawwing about GDPR on this list.
Because frankly, there's no answer that's going to make everyone happy -
largely due to a vast misunderstanding both about how HKP(S) and SKS
*work*, what the GDPR actually *says*, and its actual functional *limits*.

That said, these are indisputable *facts*:

1.) The GPG/PGP/OpenPGP[0] Web-of-Trust model and SKS network are
designed to:

   a.) be DECENTRALIZED.

   b.) be a *PUBLIC* SERVICE.

   c.) have immutable keys and signatures (keys and signatures are
designed to be tamper-proof, or at the LEAST tamper-evident), and

   d.) have keys *unable to be removed*, only revoked. The syncing
protocol simply *does not* allow this, and there are numerous posts
explaining why. There is plenty of theory as to why allowing this would
be bad practice as well, none of which have to do with GDPR - they are
purely cryptographic theory applications in nature.

2.) Dumps are considered best-practice (nay, operationally required) to
turn up a new keyserver.

   a.) Just as individual keyserver operators have deltas that vary from
the pool, so will their keydumps.

   b.) This, dumps will be different from keyserver to keyserver.

   c.) As pointed out, dumps are a great boon especially to maintaining
keyservers in political climates that may be hostile to GPG concepts. As
such, enforcing a requirement of positive personal identification
*simply* to fetch the dump is antithetical to that purpose, as it puts
said would-be operator at risk.

3.) The purpose of keyservers is for users to *look up and fetch a
(public) key*.

4.) *Real* identifiable personal information is by *no means* a
requirement for the creation of a key, nor making it available on a
keyserver. Granted, you're going to face some challenges at a
traditional keysigning party, but simply


Now for the GDPR relevance.

All of the attributes of point #1 are *required* to have a system that
keeps key integrity. There's a lot of talk about Keybase, but they're a
third party and they are a single point of control. They may *say*
they're GDPR-compliant, and they may *appear* to be GDPR-compliant, but
what guarantee can be provided that they aren't providing this
information to law enforcement/other government agencies/business/the
like? GDPR proponents put *far* too much faith in a piece of paper.
Sure, the Keybase software is open source. The entity, Keybase.io, is
not (and as such, so are its operations). I have nothing against Keybase
the entity. I like them. They've done great things for public crypto.
That doesn't mean I necessarily trust them (which is why I refuse to use
my private key with them; I do it all through GPG pipes - I may not know
the entirety of my system and the code that runs on it, but I know my
system and the code that runs on it better than I do Keybase).

Additionally, Keybase provides no safeguard against data harvesting. You
can go to any user's profile, copy their ASCII-armored public key by
clicking on the key fingerprint, and piping that into "gpg
--list-packets". Tada. You now have the same info you would on any SKS
server. Which brings me to my next point...

Putting your faith entirely in GDPR is a grave mistake, because
something (as shown) can be GDPR-compliant and lead one entirely to put
MORE faith in something despite there being no reason to, thus exposing
MORE of your own information. A piece of paper will not fix bad OPSEC.
Period. If you have a risk model where the information you attach to a
key is an issue, that is - quite frankly - a "you" problem and you
shouldn't be creating keys that can be tied to your identity.

For the armchair lawyers, the actual offical text of the GDPR can be
found here[1a] with a slightly more navigation-friendly interface
here[1b].[2]

Take special notice of Article 89[3].

This means not only are keydumps allowed for research (§2), but the SKS
in general (ESPECIALLY US servers and operators, which I'll get to in a
moment) is exempt - we provide "...archiving purposes in the public
interest" (§3). Frankly put, we make GPG *work*. GPG is a *very*
valuable public tool - zero-trust-model public cryptography is
impossible without the Web-of-Trust. Ergo, exempt. It's that simple. I
notice I'm the only one actually referencing the GDPR so far in this
discussion instead of what the nominal "I" *think* it means. Read it
sometime if you're going to concern-troll over it.

IANAL, but only one person in this discussion has mentioned that they
HAVE consulted one that specializes in data privacy - who confirms that