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@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 _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users