New keyserver at keys.openpgp.org - what's your take?

[David]

On 01/07/2019 14:55, Andrew Gallagher wrote:
> On 2019/07/01 14:26, Robert J. Hansen wrote:
>> A thought that would unfortunately require an adjustment to the OpenPGP
>> spec itself: why do we put certification signatures on the target's
>> certificate, anyway?
> 
> I think it's mostly to do with key size. This works fine either way when
> it's among peers, but in large organisations you'll tend to get one key
> that certifies a large number of others, while the median number of
> certifications made by any of the other keys is zero. Better to
> distribute lots of keys each with one signature, than lots of keys with
> no signatures and one key with all the signatures.
> 
> Also, given that there tend to be a small number of super-certifiers, it
> is easier to trace back the possible verification paths given a list of
> certifiers on a newly-encountered key. The question is rarely "what is
> the list of the keys that I can verify?", and almost always "how can I
> verify this particular key?". X509 uses this model also, and for the
> same reason.
> 
>> The current debacle is completely the result of allowing *anyone* to
>> append a cert signature to *anyone else's* cert.
> 
> Yes, which is why we've informally had "let the owner choose whether to
> publish her incoming certifications" as best practice for a long time.
> Cross-signing would enforce this, but the client-side tooling is lacking.
> 
>>> * It MUST cryptographically verify all fetched material.
>>
>> Note that this amounts to "SKS must die".  SKS does no cryptographic
>> verification of material.
> 
> SKS as we know it must die, but I think that has been obvious for a
> while. Its reconciliation algorithm can live on, however. The crypto
> verification doesn't need to be performed in the synchroniser. It might
> be best if it didn't so that we don't run into potential issues re some
> systems being able to verify, a new algorithm and some not. Better to
> let the synchroniser just do its job, and move all the verification and
> caching stuff to a higher level. It need not be in the same binary.
> 
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 

My take on all this is that I have had to disable Enigmail because it's
screwed - I was not able to send mail and all the settings in enigmail
were lots of ???????????? so I have been infected :(

David
-- 
People Should Not Be Afraid Of Their Government - Their Government
Should Be Afraid Of The People - When Injustice Becomes Law, REBELLION
Becomes A DUTY! Join the Rebellion Today! https://gbenet.com