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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180613/b5cae6c3/attachment.sig>