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