gnupg at leo.gaspard.ninja
Tue Jan 16 19:17:58 CET 2018
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) , 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
> 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
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?
More information about the Gnupg-users