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
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
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 runn
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
> 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
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 k
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, non
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
-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
On 16/01/18 15:54, Robert J. Hansen wrote:
> 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.
I think that's not really the issue. You can share the key all you want,
it just won't be provided t
> 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 the
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 sta
> (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
> discussio
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
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?
--
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
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
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
pri
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/R
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 m
> 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
(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 i
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 a
> 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'
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" a
> 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
On 01/15/2018 06:53 PM, Andrew Gallagher wrote:
On 15 Jan 2018, at 16:39, Stefan Claas 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. Ot
27 matches
Mail list logo
