[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
specifically, for a US keyserver operator operating a US keyserver, GDPR
has *absolutely no bearing* even if we *weren't* exempt. Just as the
DMCA has no bearing in, say, GB or CN as it is US legislature, so does
the GDPR not have any bearing in the US as it is EU legislature. A US
business' *EU presence* may be threatened by GDPR, but not the US entity
itself.

Lastly, enough with the strawmanning. Of *course* people are concerned
with privacy. *We wouldn't be running keyservers if we weren't.*[4] We
recognize the technological *requirements* of public cryptography, and
we recognize that quite frankly the GDPR has no bearing on them.
Frankly, the attempt to question their concern for privacy simply
because they don't support a certain legislation *that isn't even
enforceable on them* is transparently disgusting, juvenile,
thick-headed, and frankly has no place on this list.

Now. Can we actually talk about USEFUL things, like an SKS rewrite or
HKP(S) overhaul?

Thanks.


[0] I will use the generic term "GPG" moving forward to refer to the
OpenPGP standards and protocols, GPG, HKP(S), etc.
[1][a]
https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679&from=EN
   [b] https://gdpr-info.eu/
[2] I am not associated with any of the mentioned/referenced/linked-to
organization(s)/firm(s).
[3] https://gdpr-info.eu/art-89-gdpr/
[4] And yes, this includes the blatant "think of the/your children"
attempt as well. This is no less than an attempt at emotional
manipulation, and will not be tolerated in civil discussion.


On 8/16/19 18:24, Stefan Claas wrote:
> Hendrik Visage wrote:
> 
>>> On 16 Aug 2019, at 23:29 , Stefan Claas <address@hidden> wrote:
> 
>>> Please explain in 2019 to you friends, wishing to learn secure email
>>> communications, that they should use PGP, while everybody can sign
>>> their pub key with arbritary  (and illegal) data, thanks to SKS.
>>
>> The signature is a indication of who knows you, and SKS is a mechanism, not
>> the only mechanism to setup a web of trusts
> 
> ??? Mr. or Mrs. X signs my pub key, put some 'funny stuff' on it, without
> my knowledge and I should know these people? Or look at prominent people's
> keys with lots of sigs, while the key holder does not sign back ... Do
> you think that those prominent key holders know the signers, or could
> it be the case that those are only fan sigs, bringing no weight to the
> WoT?
> 
>>> They will for sure show you a stinking finger.
>>
>> You aren’t forced to be part of, nor use, the SKS.
> 
> Correct. I recently saw that my current pub key was uploaded, while
> I am no longer part of SKS. Others may think that I am still using
> SKS. :-(
>  
>>> A public key in 2019 does not mean that it can be used for nasty
>>> things, while a public key holder can not defend him  / her self!
>>
>> I may have an outer wall that get’s grafiti all the time… I can’t protect
>> that every single minute of the day… but I can proof it is my home given the
>> fact that only I have a set of keys that will open the (full of grafiti)
>> garage door!!
>>
>> that public key’s “signing” is the perpetrator that acknowledges it’s my key,
>> even if/when he/she/they/them/whatever put horrible things on it, they are
>> still the ones that can be shown as the ones that did it…
> 
> ??? Then please tell us who did the 'funny' sigs on Facebook's pub key.
> 
>>> May I ask why you SKS operators did not implemented GnuPG's
>>> feature the --no-modifiy flag? It is not a brand new feature …
>>
>> Perhaps as it’s not running GnuPG/pgp inside the SKS key servers ;)
> 
> Mmmhhh ... and nobody liked to tackle this issue ...
> 
>> SKS is just a mechanism to share (decentralized) a blob of data with a random
>> number ID
> 
> Yes, unfortunately.
> 
> Regards
> Stefan
> 
> 
> 
> 
> 


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

signature.asc
Description: OpenPGP digital signature