Re: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]

[Andrew Gallagher]

On 13/06/18 14:43, Daniel Kahn Gillmor wrote:
> the proposed revocation distribution network wouldn't allow any user IDs
> or third-party certifications, so most of the "trollwot" would not be
> relevant.

As I see it, the keyservers perform two related but distinct functions -
finding unknown keys by UID, and finding updates to known keys by
fingerprint.

All the current issues are related to the first function, but the first
function has several alternative solutions available (DNS, WKD, Keybase,
attaching pubkeys to every email...). If this first function were to
fail overnight, it would be an inconvenience but not a disaster.

But there is no known alternative to the second function, which is the
distribution of key updates, including revocations. Therefore I believe
the immediate priority should be to protect update distribution.

How to prevent abuse of a distributed, unauthenticated store of
arbitrary data remains an unsolved problem (see: usenet). If the
keyservers are to remain unauthenticated and distributed, then the only
option is to prohibit arbitrary data. That means no arbitrary data
fields (i.e. no UIDs) and no arbitrary data in structured data fields
(i.e. validity checks on self-sigs). This will shrink the size of the
database significantly, but impose some processing cost.

There are two ways forward: a new network of key-material-only servers,
or restricting the existing network to key material only. In the first
case, we would still need a means to propagate keys between the old and
new networks during the transition. And in the second case, we would
need to handle an intermediate state where only some servers have been
upgraded to the new version.

So no matter what we do, we will still need to have some method of doing
fake recon with legacy sks instances. The question is how to arrive at
this state most efficiently. I would suggest that since recon is at the
root of the problems, we should concentrate on the recon process itself.
If uploading a bad key takes down one server then fine, we can lose one
server. But the badness must not infect other servers automatically.

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]

[Daniel Kahn Gillmor]

On Wed 2018-01-17 08:57:12 +0100, Kristian Fiskerstrand wrote:
> On 01/17/2018 01:20 AM, Daniel Kahn Gillmor wrote:
>> On Tue 2018-01-16 22:56:58 +0100, Kristian Fiskerstrand wrote:
>>> thanks for this post Daniel, my primary question would be what advantage
>>> is gained by this verification being done by an arbitrary third party
>>> rather by a trusted client running locally, which is the current modus
>>> operandus. Any keyserver action doing this would just shift
>>> responsibilities to a third party for something better served (and
>>> already happens) locally.
>> 
>> the advantage is spam-abatement -- the keyservers have to keep track of
>> what is attached to each blob they transport/persist.  if all signatures
>> that they transport for a given blob are cryptographically certified,
>> then only the original uploader of that blob can make assertions about
>> it; other people can't spam the blob to make it untransportable.
>
> All the certificates used in trollwot are technically correct. You can
> still use the same mechanisms as you control the other key material, and
> can use intentionally weak key material if wanting to speed things up.

sorry for the blast from the past here, but in re-reading this thread, i
thought i'd follow up on this.

the proposed revocation distribution network wouldn't allow any user IDs
or third-party certifications, so most of the "trollwot" would not be
relevant.

if someone wants to upload their own key and make it unfetchable by
appending garbage to it, that's probably OK (at least, it's a strict
improvement than the current situation, which is that they can append
garbage to *any* key).  and if they use weak key material (or publish
the secret someplace), then sure it's a noisy blob that anyone can
append to.  But no one will care, because they aren't likely to be
relying on that key.

does that make sense as to why this proposal is potentially useful?

--dkg


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]

[Kristian Fiskerstrand]

On 01/17/2018 01:20 AM, Daniel Kahn Gillmor wrote:
> On Tue 2018-01-16 22:56:58 +0100, Kristian Fiskerstrand wrote:
>> thanks for this post Daniel, my primary question would be what advantage
>> is gained by this verification being done by an arbitrary third party
>> rather by a trusted client running locally, which is the current modus
>> operandus. Any keyserver action doing this would just shift
>> responsibilities to a third party for something better served (and
>> already happens) locally.
> 
> the advantage is spam-abatement -- the keyservers have to keep track of
> what is attached to each blob they transport/persist.  if all signatures
> that they transport for a given blob are cryptographically certified,
> then only the original uploader of that blob can make assertions about
> it; other people can't spam the blob to make it untransportable.

All the certificates used in trollwot are technically correct. You can
still use the same mechanisms as you control the other key material, and
can use intentionally weak key material if wanting to speed things up.


-- 

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

"We all die. The goal isn't to live forever, the goal is to create
something that will."
(Chuck Palahniuk)



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]

[Daniel Kahn Gillmor]

On Tue 2018-01-16 22:56:58 +0100, Kristian Fiskerstrand wrote:
> thanks for this post Daniel, my primary question would be what advantage
> is gained by this verification being done by an arbitrary third party
> rather by a trusted client running locally, which is the current modus
> operandus. Any keyserver action doing this would just shift
> responsibilities to a third party for something better served (and
> already happens) locally.

the advantage is spam-abatement -- the keyservers have to keep track of
what is attached to each blob they transport/persist.  if all signatures
that they transport for a given blob are cryptographically certified,
then only the original uploader of that blob can make assertions about
it; other people can't spam the blob to make it untransportable.

--dkg

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]

[Andrew Gallagher]

> On 16 Jan 2018, at 22:26, Leo Gaspard  wrote:
> 
> It could also help limit the impact of the nightmare scenario RJH has
> described, by making sure all the data is “cryptographically valid and
> matching”, thus making it harder to just propagate arbitrary data down
> the network.

It would make it *very* slightly more computationally expensive to pull off, 
but would not limit the impact one bit. 

A

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]

[Leo Gaspard]

On 01/16/2018 10:56 PM, Kristian Fiskerstrand wrote:
> On 01/16/2018 07:40 PM, Daniel Kahn Gillmor wrote:
> 
>> The keyserver network (or some future variant of it) can of course play
>> a role in parallel to any or all of these.  for example, keyservers are
>> particularly well-situated to offer key revocation, updates to expiry,
>> and subkey rotation, none of which would necessarily involve names or
>> e-mail addresses.
>>
>> It would be interesting to see a network of keyserver operators that:
>>
>>  (a) did cryptographic verification, and rejected packets that could not
>>  be verified (also: required cryptographic verifications of
>>  cross-signatures for signing-capable subkeys)
>>
>>  (b) rejected all User IDs and User Attributes and certifications over
>>  those components
>>
>>  (c) rejected all third-party certifications -- so data attached to a
>>  given primary key is only accepted when certified by that primary
>>  key.
>>
> 
> thanks for this post Daniel, my primary question would be what advantage
> is gained by this verification being done by an arbitrary third party
> rather by a trusted client running locally, which is the current modus
> operandus. Any keyserver action doing this would just shift
> responsibilities to a third party for something better served (and
> already happens) locally.

I guess one argument could be “when lazy people use the keyserver
network, they likely get not-too-bad data”.

I seem to remember that when a keyserver returned multiple keys to
GnuPG, GnuPG imported both, even when searching for a fingerprint and
the fingerprint didn't match, at some point in the last few years? If
even GnuPG can fail at properly sanitizing the data received by
keyservers (and I hope I'm not mistaken in this memory), I guess having
such keyservers only serve curated data when used in their “nominal” use
could help a bit.

It could also help limit the impact of the nightmare scenario RJH has
described, by making sure all the data is “cryptographically valid and
matching”, thus making it harder to just propagate arbitrary data down
the network. Then I don't have the structure of an OpenPGP key in mind,
so maybe this would not work due to fields in the key that could be set
to arbitrary data anyways

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]

[Kristian Fiskerstrand]

On 01/16/2018 07:40 PM, Daniel Kahn Gillmor wrote:

> The keyserver network (or some future variant of it) can of course play
> a role in parallel to any or all of these.  for example, keyservers are
> particularly well-situated to offer key revocation, updates to expiry,
> and subkey rotation, none of which would necessarily involve names or
> e-mail addresses.
> 
> It would be interesting to see a network of keyserver operators that:
> 
>  (a) did cryptographic verification, and rejected packets that could not
>  be verified (also: required cryptographic verifications of
>  cross-signatures for signing-capable subkeys)
> 
>  (b) rejected all User IDs and User Attributes and certifications over
>  those components
> 
>  (c) rejected all third-party certifications -- so data attached to a
>  given primary key is only accepted when certified by that primary
>  key.
> 

thanks for this post Daniel, my primary question would be what advantage
is gained by this verification being done by an arbitrary third party
rather by a trusted client running locally, which is the current modus
operandus. Any keyserver action doing this would just shift
responsibilities to a third party for something better served (and
already happens) locally.


-- 

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

Bene diagnoscitur, bene curatur
Something that is well diagnosed can be cured well



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

key distribution/verification/update mechanisms other than keyservers [was: Re: a step in the right direction]

[Daniel Kahn Gillmor]

On Tue 2018-01-16 01:02:11 +, listo factor via Gnupg-users wrote:
> Burning it down is not what I was advocating. I am advocating orderly
> evacuation and replacement of a system that has clearly outlived its
> usefulnesses. If it is not replaced in time, it will, at some point,
> burn ignited by forces we have no control over. ~Then~ it will have
> to be abandoned in rather more painful manner - just as you are
> alluding to.

While i think we disagree on "has outlived its usefulnesses", i would
agree that planning and preparing for catastrophic keyserver network
failure is a good idea.  What i haven't seen in this thread is a list of
the variety of proposals for OpenPGP key distribution that do *not*
require the global append-only keyserver network.

So in the hopes of making this a productive discussion, i'll list a
few.  Already briefly mentioned are:

 * Web Key Directory (WKD)
 Mail provider publishes public keys of users via https to a
 well-known location.

 https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-05

 * Keybase
 social media and other avenues for key publication, identification,
 and corroboration.

 https://keybase.io

A few other approaches are:

 * DNS OPENPGPKEY records
 DNS lookups of public keys (or hashes of public keys for
 confirmation)
 
 https://tools.ietf.org/html/rfc7929

 * Autocrypt
 In-band key exchange (in every e-mail message) removes the need for
 external distribution mechanisms for all messages but the first.
 
 https://autocrypt.org/

 * VVV
 DNS (SRV) discovery of HKP service operated by the mail provider.

 https://keys4all.de/media/beschreibung-vvv-loesung.pdf

I'm sure i've missed some other distribution/verification/update
mechanism, and would be happy to see constructive pointers.

Of the above, i'm most leaning toward Autocrypt today, because it does
not require involvement of any third party -- as long as both sides of
the e-mail use an autocrypt-capable client, there is no additional
information leakage.

Note that the different schemes have different properties in terms of:

 * information leakage
 * cryptographic verification
 * third-party control
 * censorship
 * ...

The keyserver network (or some future variant of it) can of course play
a role in parallel to any or all of these.  for example, keyservers are
particularly well-situated to offer key revocation, updates to expiry,
and subkey rotation, none of which would necessarily involve names or
e-mail addresses.

It would be interesting to see a network of keyserver operators that:

 (a) did cryptographic verification, and rejected packets that could not
 be verified (also: required cryptographic verifications of
 cross-signatures for signing-capable subkeys)

 (b) rejected all User IDs and User Attributes and certifications over
 those components

 (c) rejected all third-party certifications -- so data attached to a
 given primary key is only accepted when certified by that primary
 key.

This would basically be a network that facilitates
update/revocation/key-rotation, without exposing any names or e-mail
addresses to the public by default; it could be run in parallel with the
existing keyserver network.  i don't know how well we could bridge the
two networks, though and it'd be a shame to have to upload updated
keys to both networks manually. :/

anyway, hopefully this gives some concrete, positive next steps that
folks who want the keyserver network to go away can take, rather than
trying to burn it all down :)

   --dkg


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: a step in the right direction

[Duane Whitty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 18-01-16 10:54 AM, Robert J. Hansen wrote:
>> (Oh, by the way, usually when I talk about DRM, I'm talking about
>> giving somebody data but restricting the ways in which they can
>> use that data. It's not clear to me how DRM applies when you want
>> to simply not give data at all, to anybody. But this is not
>> really pertinent to the discussion, so never mind.)
> 
> I was the one who brought up DRM.
> 
> What Stefan and Listo want is some mechanism by which, if I have a
> copy of their public key, I can be prohibited from sharing that
> with a keyserver.  How I get to use data in my possession is
> controlled by a third party -- that's DRM.  In this case it's a
> voluntary, half-assed DRM scheme, but it's still in the family of
> DRM schemes.
> 
> 
> 
> 
> ___ Gnupg-users mailing
> list Gnupg-users@gnupg.org 
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 
Maybe something akin to patent law here would work better than a
technological solution.  Once you share something it is public unless
you force the the receiving party to sign a non-disclosure document.

Once you share your public key with even one person it is in the
public domain.  If you want to make it painful enough to prevent this
from happening have the receiving party sign a contract of
non-disclosure which stipulates what the penalties will be if the
break the contract.  Just my two cents and I'm sure it doesn't cover
everything.



Best Regards,
Duane

- -- 
Duane Whitty
du...@nofroth.com
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJaXlCfAAoJEOJfpr8UVxtkwgsH/3V+ZCc839yIENQDgp/Z7/Yj
3TVRRw/ELswj9emAebtIMiY5EYvQp3zhL71sTnXq8+ez0k2oc68ow4oxnwpl+9K1
psQiPVm45ouQlBlS9YJ6O8KBQRFARmP3fDt+JAwQ9a/PJRfqefdk93gVM89T+9VM
V6NzkR9ktyokNmKhKi48oVXIVw2XX2DG2fuspI2QwZLqtt0PxmGdDuyiWmFZKigW
mWU3evTAkzQtslsppVNenJjZjrz7XIqt/xq/CEf/PgfreeY+g7chm+fzpdvSuTMu
9hJWOkXBTx+W40/5GbLyzpSYlKcUyu8evrN8Z9Uo5CtX0E+c30cCQ0auLkPKV8o=
=KRTM
-END PGP SIGNATURE-

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: a step in the right direction

[Robert J. Hansen]

> while i agree with rjh that destruction of the current SKS-based
> keyserver network (either by technical or legal means) would today be a
> net loss, this statement goes too far.

I welcome the correction, but I stand by my statement.  Many users,
particularly in corporate environments, roll their own packages and rely
on the keyservers to propagate those signing keys worldwide.  I know
I've seen RHEL corporate networks doing this; I _believe_ I've seen
Ubuntu-based corporate networks doing this.  (Back in 2016 I wound up
doing just this task for an RHEL network, while my officemate handled
the Ubuntu machines -- I have no hands-on experience with the Ubuntu
side of things, just recollections of hearing my officemate talk about
them.)

It is correct, though, to say official Debian packages would have
minimal disruption.  Thank you.  :)



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: a step in the right direction

[Daniel Kahn Gillmor]

On Mon 2018-01-15 17:45:49 -0500, Robert J. Hansen wrote:
> _Literally every major FOSS package manager breaks.  Updates become
> impossible._

while i agree with rjh that destruction of the current SKS-based
keyserver network (either by technical or legal means) would today be a
net loss, this statement goes too far.

the debian package manager does not directly use the keyserver network,
and debian archive signing keys are themselves distributed as debian
packages.

the keyservers can occasionally be used as a way to find updated keys
for a system that has been offline for years, to "re-bootstrap" the
package manager, but dpkg and apt are certainly not reliant on the
keyserver network to do their thing.

Third-party repositories also do not need the keyservers to function
properly, if they're configured in a sensible way:

https://wiki.debian.org/DebianRepository/UseThirdParty

Regards,

--dkg


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: a step in the right direction

[Robert J. Hansen]

> (Oh, by the way, usually when I talk about DRM, I'm talking about giving
> somebody data but restricting the ways in which they can use that data.
> It's not clear to me how DRM applies when you want to simply not give
> data at all, to anybody. But this is not really pertinent to the
> discussion, so never mind.)

I was the one who brought up DRM.

What Stefan and Listo want is some mechanism by which, if I have a copy
of their public key, I can be prohibited from sharing that with a
keyserver.  How I get to use data in my possession is controlled by a
third party -- that's DRM.  In this case it's a voluntary, half-assed
DRM scheme, but it's still in the family of DRM schemes.




signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: a step in the right direction

[Stefan Claas]

Am 16.01.2018 um 13:38 schrieb Andrew Gallagher:


On 16/01/18 12:34, Stefan Claas wrote:

I don't know if such software already exists but how about using key
servers
as message storing/retrival system, so that people can avoid the classic
smtp
route for their PGP encrypted messages. Well, just a thought...

Isn't that called USENET?
Yes, something like Usenet's alt.anonymous.messages, for people who 
don't know

or have Usenet access.

Regards
Stefan


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: a step in the right direction

[Andrew Gallagher]

On 16/01/18 12:34, Stefan Claas wrote:
> I don't know if such software already exists but how about using key
> servers
> as message storing/retrival system, so that people can avoid the classic
> smtp
> route for their PGP encrypted messages. Well, just a thought...

Isn't that called USENET?

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: a step in the right direction

[Stefan Claas]

Am 16.01.2018 um 12:51 schrieb Andrew Gallagher:



So we have to distinguish between what is available if one is
sufficiently motivated to go and look, and what is shown to the majority
of users. The vandalism problem is solved by clients not displaying
unverified content. Whereas the "nightmare scenario" happens entirely
out of view of the average user, but has more serious consequences.
Let's not mix them up.

There might be also another problem in the future, not for GnuPG users, but
for key servers.

I don't know if such software already exists but how about using key servers
as message storing/retrival system, so that people can avoid the classic 
smtp

route for their PGP encrypted messages. Well, just a thought...

Regards
Stefan


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: a step in the right direction

[Andrew Gallagher]

On 16/01/18 10:57, Stefan Claas wrote:
> And do people always look into blockchain data, when using their wallet to
> do transactions? With public WWW key servers it is imho different.

This is an important distinction.

Ordinary users should not be browsing the raw data. They should be using
tools such as Enigmail that filter out unverified data from their
default views. Sure, if you want to go looking for all the junk
signatures on people's keys you can, but it shouldn't be displayed as a
matter of course.

Now, for various reasons a lot of us on this list have spent far too
much of our lives looking at the raw keyserver data. And similarly, I
have no doubt that a lot of early Bitcoin adopters have looked at the
raw blockchain data.

So we have to distinguish between what is available if one is
sufficiently motivated to go and look, and what is shown to the majority
of users. The vandalism problem is solved by clients not displaying
unverified content. Whereas the "nightmare scenario" happens entirely
out of view of the average user, but has more serious consequences.
Let's not mix them up.

-- 
Andrew Gallagher



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: a step in the right direction

[Stefan Claas]

Am 16.01.2018 um 11:35 schrieb Peter Lebbing:


On 16/01/18 04:24, listo factor via Gnupg-users wrote:

Considering the possibility that this particular system will
be forced to conform to a more contemporary (and I would argue
more enlightened) legislative framework in respect to the right to
privacy (cf., https://en.wikipedia.org/wiki/Right_to_be_forgotten)

So how about I insert some private information of somebody into the
"more contemporary" Bitcoin blockchain. Would you advocate that
everybody removes copies of the blockchain? Wouldn't that mean an end to
Bitcoin?



The blockchain is not anonymous and the origin can be traced back, right?
And do people always look into blockchain data, when using their wallet to
do transactions? With public WWW key servers it is imho different.

Regards
Stefan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: a step in the right direction

[Peter Lebbing]

On 16/01/18 04:24, listo factor via Gnupg-users wrote:
> Considering the possibility that this particular system will
> be forced to conform to a more contemporary (and I would argue
> more enlightened) legislative framework in respect to the right to
> privacy (cf., https://en.wikipedia.org/wiki/Right_to_be_forgotten)

So how about I insert some private information of somebody into the
"more contemporary" Bitcoin blockchain. Would you advocate that
everybody removes copies of the blockchain? Wouldn't that mean an end to
Bitcoin?

Or do you consider blockchains to be outmoded technology from a
different era? Just kidding :-).

> then it is not unreasonable to assume that most enlightened
> jurisdictions will sooner or later enact such legislation. Yes, it
> is DRM, but in my view ethically much more justifiable than DRM over
> the data of commercial value.

What about those enlightened jurisdictions where anything not conforming
to a strict interpretation of the local major religion is forbidden?
Should country A get to forbid anything that is not directly conforming
to religion 1 and country B forbid anything not conforming to religion
2, and this world-wide? Perhaps then we can use all those high-bandwidth
links to exchange nothing but kitten pictures... provided there isn't a
religion forbidding the depiction of animals.

Why would you honour the EU's request to purge unwanted information from
the internet world-wide, but not honour country A and B? Who decides
what is "ethically justifiable" and what not? Do we need a world-wide
vote on which commission is the most enlightened to decide this? Would
such a vote require a majority, a large majority or be unanimous? And
who decides these parameters anyway? And when there's a radical regime
change somewhere in the world, do we go back to the drawing board?

(Oh, by the way, usually when I talk about DRM, I'm talking about giving
somebody data but restricting the ways in which they can use that data.
It's not clear to me how DRM applies when you want to simply not give
data at all, to anybody. But this is not really pertinent to the
discussion, so never mind.)

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: a step in the right direction

[Leo Gaspard]

On 01/16/2018 09:20 AM, Robert J. Hansen wrote:>> should not be viewed
as "discussing a [...] nightmare scenario",
> 
> I am darkly amused at someone who has not done the research into what
> the nightmare scenario *is* telling me that it's not a nightmare scenario.
> 
> The nightmare scenario is malcontents realize the keyserver network is a
> multijurisdictional, redundant, distributed database from which data
> cannot be deleted... and decide this makes it an ideal way to distribute
> child porn.  The moment that happens, the keyserver network goes down
> hard as every keyserver operator everywhere gets exposed to massive
> criminal liability.
> 
> We've known about it for several years.  We've been thinking about how
> to counter it for several years.  It turns out that countering it is a
> *really hard job*.  If you make it possible to delete records from a
> keyserver, you open the door to all kinds of shenanigans that
> governments could force keyserver operators to do on their behalf.

I think this may be the reason why others than you are much more
optimistic than you about all this: I don't think we are considering
this scenario, only the much more restricted case of “I want to remove
information associated with my private key”. In which case there is no
need of trusted introducers who would be allowed to moderate data, or
anything like this: the owner of the key could just sign the deletion
token with the said key.

Handling network-wide censorship of information published is a much
harder scenario, as the network was designed to be censorship-resistent.
And it looks like a nice property we would want to keep at network-level
in my opinion, though in order to accomodate local jurisdictions
keyserver operators could maybe want not to store eg. photo IDs or the
like -- just like if I understand correctly the case of someone sueing
to get his key removed from keyservers lead to the addition of an option
for keyserver operators to refuse syncing certain keys.

That said, I did read your “To implement this would require a completely
new keyserver implementation, […]” ; this message was just to maybe cast
some light on why some people look much more optimistic about this than
you are.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: a step in the right direction

[Robert J. Hansen]

> I'd suggest speaking up over at sks-de...@gnu.org, where people have

Correction: sks-de...@nongnu.org

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: a step in the right direction

[Robert J. Hansen]

(I originally composed this on a mobile device and it was held for
moderation.  Re-sending it from my laptop.)

=

(Apologies for the terseness: on a mobile device)

> should not be viewed as "discussing a [...] nightmare scenario",

I am darkly amused at someone who has not done the research into what
the nightmare scenario *is* telling me that it's not a nightmare scenario.

The nightmare scenario is malcontents realize the keyserver network is a
multijurisdictional, redundant, distributed database from which data
cannot be deleted... and decide this makes it an ideal way to distribute
child porn.  The moment that happens, the keyserver network goes down
hard as every keyserver operator everywhere gets exposed to massive
criminal liability.

We've known about it for several years.  We've been thinking about how
to counter it for several years.  It turns out that countering it is a
*really hard job*.  If you make it possible to delete records from a
keyserver, you open the door to all kinds of shenanigans that
governments could force keyserver operators to do on their behalf.

How do you make it possible to delete records from a keyserver, while at
the same time keeping the keyserver resistant to malicious tampering
from adversaries?

This is an incredibly hard question to address.  And frankly, you're not
adding a single iota to the discussion.  But if you want to continue it,
I'd suggest speaking up over at sks-de...@gnu.org, where people have
been having this discussion off and on for years.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: a step in the right direction

[listo factor via Gnupg-users]

On 01/16/2018 01:17 AM, Robert J. Hansen - r...@sixdemonbag.org wrote:


The SKS community has been discussing a considerably worse nightmare
scenario for the past seven years.


Considering the possibility that this particular system will
be forced to conform to a more contemporary (and I would argue
more enlightened) legislative framework in respect to the right to
privacy (cf., https://en.wikipedia.org/wiki/Right_to_be_forgotten)
should not be viewed as "discussing a [...] nightmare scenario",
it should be considered as planning for demands that will be placed
on the system by developments outside of it, i.e., by developments
of the society that the system is supposed to serve.

If there is merit to the principle that an Internet server operator
can not keep publicly serving private data over the objections of
the owner (the same as today, after many battles, he can no longer
publicly serve data of commercial value over the objections of its
owner), then it is not unreasonable to assume that most enlightened
jurisdictions will sooner or later enact such legislation. Yes, it
is DRM, but in my view ethically much more justifiable than DRM over
the data of commercial value.

The fact that one large jurisdiction is well on its way with
enacting this, while another is not there yet, should be viewed
as a fortunate circumstance, one that buys us time to do what needs
to be done, not as an excuse to bury our heads in the sand.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: a step in the right direction

[Robert J. Hansen]

> I would never allow my opinion of what are the "good places" and what
> are the "bad places" to enter into a technical discussion.
> (On immigration, or on security engineering).

I think you'll have a hard time convincing people that when speaking
about human rights activists in North Korea, it's somehow inappropriate
to say they're living in a bad place.  Repressive governments are real
threats to human rights, and it doesn't do anyone any good to pretend
otherwise.

> Burning it down is not what I was advocating. I am advocating orderly
> evacuation and replacement of a system that has clearly outlived its
> usefulnesses.

No, you're not.

Evacuation and replacement requires a replacement exists.  The moment
you present an alternative that's running and working and stable, *then*
we can have a discussion about moving to the exits.

> EU legislation, among other things, will see to that. The times are
> changing, and nobody is free to keep serving publicly someone else's
> private information over the objections of the owner.

US keyservers are.  The only thing EU regulations will do is end
keyservers in the EU.

The SKS community has been discussing a considerably worse nightmare
scenario for the past seven years.  There have been a number of flawed
proposals made in that time period.  Your time might be better spent
perusing the last seven years of sks-devel to learn what has already
been proposed and the flaws in each of them.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: a step in the right direction

[listo factor via Gnupg-users]

On 01/15/2018 10:45 PM, Robert J. Hansen - r...@sixdemonbag.org wrote:

Which would be step in the right direction when compared
with the current situation.



..> First, people in bad places like Syria and Iran lose the ability to...

I would never allow my opinion of what are the "good places" and what
are the "bad places" to enter into a technical discussion.
(On immigration, or on security engineering).

...

_Literally every major FOSS package manager breaks.  Updates become
impossible._

Let that sink in for a moment.

I don't think you understand anything about the ecosystem here.  You're
advocating burning down a _critically important part of the entire FOSS
landscape._


Burning it down is not what I was advocating. I am advocating orderly
evacuation and replacement of a system that has clearly outlived its
usefulnesses. If it is not replaced in time, it will, at some point,
burn ignited by forces we have no control over. ~Then~ it will have
to be abandoned in rather more painful manner - just as you are
alluding to.

EU legislation, among other things, will see to that. The times are 
changing, and nobody is free to keep serving publicly someone else's

private information over the objections of the owner. "This is the
way we always did it" is a poor response and it will not be a valid
one forever.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: a step in the right direction

[Robert J. Hansen]

> Which would be step in the right direction when compared
> with the current situation.

... shutting down a keyserver network relied on by literally tens of
thousands of people, to say nothing about OS distributions, is a "step
in the right direction"?

Okay.  Fine.  Let's say you wave a magic wand and you're able to make
the keyserver network go away.  What are the immediate, *predictable*,
consequences?

First, people in bad places like Syria and Iran lose the ability to
easily get public keys for journalists in free countries.  The neat
thing about the pool is nobody knows exactly who all is in it.  Years
ago for some months I ran a covert keyserver to see how practical it
would be for people in hostile regimes: my keyserver was not part of the
public pool, but synced with it.  That's useful because a regime might
firewall off the entire pool, but so long as covert nodes exist the
whole of the network is still accessible even in information-controlling
regimes.

Second, your operating system -- if you're running something like a
Linux distro, or macOS using Homebrew, or heck, even Windows with
msys2/mingw -- *BREAKS*.  You can't get updates any more.  Let's look at
why, using the package manager in msys2/mingw/Arch Linux.  It's called
pacman.

In pacman, each package is signed by the package maintainer.  The
package maintainer's certificate is in turn signed by at least three
other pacman maintainer certs.  E.g., if you manage a package called
"fooblitzsky", you sign the fooblitzsky packages with your cert, and
three msys2 maintainers sign your cert.  This way, end users can be
confident that you, the maintainer, personally authorized this release,
and that you're trusted by the msys2 team.

Now that you've taken down the keyserver network, you go to install
fooblitzsky, and ... uh ... wait.  You can get the package, but you have
no way of getting the maintainer's cert to verify the package.

_Literally every major FOSS package manager breaks.  Updates become
impossible._

Let that sink in for a moment.

I don't think you understand anything about the ecosystem here.  You're
advocating burning down a _critically important part of the entire FOSS
landscape._

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

a step in the right direction

[listo factor via Gnupg-users]

On 01/15/2018 06:53 PM, Andrew Gallagher wrote:



On 15 Jan 2018, at 16:39, Stefan Claas <stefan.cl...@posteo.de> wrote:

Maybe we need (a court) case were a PGP user requests the removal
of his / her keys until the operators and code maintainers wake up?


You also need to prove that removal is technically possible. Otherwise all that 
such a court case will achieve is to shut down the keyservers.


Which would be step in the right direction when compared
with the current situation.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users