Hi Kristian, > Am 27.02.2015 um 17:31 schrieb Kristian Fiskerstrand > <kristian.fiskerstr...@sumptuouscapital.com>: > > On 02/27/2015 05:26 PM, Patrick Brunschwig wrote: > > On 27.02.15 13:11, Kristian Fiskerstrand wrote: > >> On 02/27/2015 12:43 PM, Hauke Laging wrote: > >>> Am Fr 27.02.2015, 12:27:40 schrieb gnupgpacker: > >> > >>>> Maybe implementation with an opt-in could preserve > >>>> publishing of faked keys on public keyservers? > >> > >>> We need keyservers which are a lot better that today's. IMHO > >>> that also means that a keyserver should tell a client for each > >>> offered certificate whether it (or a trusted keyserver) has > >>> made such an email verification. > >> > >> The keyservers have no role in this, they are pure data store > >> and can never act as a CA. That would bring up a can of worm of > >> issues, both politically and legally, I wouldn't want to see the > >> first case where a keyserver operator was sued for permitting a > >> "fake key" (the term itself is very misleading, the key itself > >> isn't fake at all, but a fully valid key where the UID has not > >> been mated to its holder through proper validation). > > > > But that's the main primary reason of the article at all. The fact > > that anyone can upload _every_ key to a keyserver is an issue. If > > No, it is not, it has always been very clear no to rely on the > existence of a key on either a keyserver or on a local keyring without > proper verification and certification
And here’s the other problem the main article in c’t mentions: Those keys, although faked, were certified. They were certified by equally faked keys which resemble keys that are quite well-known. So unless someone had the *real* certifying keys installed and could see that those weren’t the same certifications as on the forged keys, there was no first and even second glance way of recognising these as being faked. I agree with Patrick’s point that the problem, indeed, lies in the way keys can be uploaded to key servers without at least some basic verification of key ownership. Something needs to change, and there *must* be put a mechanism into place that allows at least some assurance that the person I think the key belongs to, is actually the owner. It is not always feasible to verify a whole key finger print with the recipient first-hand, except for insecure plain text e-mail. For example, if I wanted to have sent that journalist encrypted e-mail with some important information, according to the current model, I would have had to find out a phone number to reach him, have a business card with his key’s finger print on, or met him in person to verify each other’s keys first. That’s a damn high entry level, and I think it’s time to re-think some aspects of that and integrate some means of ownership verification that avoids at least some of the above mentioned problems. Marco
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
