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 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.
I guess one argument could be “when lazy people use the keyserver network, they likely get not-too-bad data”. I seem to remember that when a keyserver returned multiple keys to GnuPG, GnuPG imported both, even when searching for a fingerprint and the fingerprint didn't match, at some point in the last few years? If even GnuPG can fail at properly sanitizing the data received by keyservers (and I hope I'm not mistaken in this memory), I guess having such keyservers only serve curated data when used in their “nominal” use could help a bit. 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. Then I don't have the structure of an OpenPGP key in mind, so maybe this would not work due to fields in the key that could be set to arbitrary data anyways _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users