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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180116/944c5f64/attachment.sig>