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

2018-07-16 Thread 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

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

2018-06-13 Thread 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

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

2018-01-17 Thread 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

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

2018-01-16 Thread 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.

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

2018-01-16 Thread 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 >

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

2018-01-16 Thread 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

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

2018-01-16 Thread 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,

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

2018-01-16 Thread 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