On 01/16/2018 06:33 PM, Kristian Fiskerstrand wrote: > On 01/16/2018 06:19 PM, Leo Gaspard wrote: >> Also, there are flaws with this approach (like after a private key >> compromise, it would allow to prevent dissemination of the revocation >> certificate) [1], but fixes like allowing the statement to be “on >> 2018-04-01, please expose only the master key and its revocation >> certificate(s) to clients” would likely handle this particular issue. >> >> All I'm saying is that a system like this one is not a silver bullet >> solution, but may handle a few of the current complaints against the SKS >> network? > > Not really (and that is ignoring disagreement with the complaints to > begin with). > > One issue with the first statement "please allow to be on keyserver" is > that it doesn't provide any verification that the email in UID (or just > the name) is accurate, so most of the complains regarding occurrence of > multiple matches for a search would not be honored, as you could anyways > create multiple keyblocks with this property.
Hmm, I was thinking only about de-listing information someone inadvertently made public, not about having the keyservers become CAs (which I don't think should happen, even though from a UI perspective it's easier when things are centralized). I must say I basically took only the “please delist me” signature packet into account in my answer, not the “please list me”, as I don't think it would bring large improvements. That said, thanks for the link! Just curious, I never saw information about this in enigmail, do you know whether it has been implemented yet? _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users