looking up pgp keys

[Arturo 'Buanzo' Busleiman]

The human side of things (the WoT) must always be separated from
keyservers, which are just a convenient key search/publish/obtain system.

I have (slowly) been working on openpgp extensions for http for the past
six+ years (enigform and mod_openpgp). I am now working on a decentralized
secure IM. As most secure systems it will probably be difficult for people
that do not requiere such level of security.

We have already seen what happens when the delicate balance of ease of use
and/or functionality versus security is affected.

It hurts a bit, doesnt it, when we see that security is so hard to provide
for the end user. :(
 On Sep 12, 2013 4:03 AM, "John Clizbe" <John at enigmail.net> wrote:

> Phil Pennock wrote:
> > On 2013-09-12 at 03:20 +0200, Hauke Laging wrote:
> >> If the WoT is ever to be taken seriously (the obvious comparison is the
> >> signature law with its requirements for CAs) then this MUST be(come) the
> >> server's responsibility. If you cannot know (in a way you can prove)
> whether
> >> the information you get from the server is the current state of the
> >> certificate then the information is close to useless.
> >
> > So who or what are you wanting to trust, and under what circumstances?
> >
> > The moment you start talking about compliance with signature law, I
> > infer that you expect the keyservers to be liable for any malicious data
> > present, even if validation has occurred but the attacker worked to
> > deceive multiple people to get their data in.  If this happens, I for
> > one will stop running a public keyserver: I'm not taking on public
> > liability for the actions of others, which I can't prevent, and with the
> > liability being to a public which is too often misled by persuasive
> > idiots who don't understand the basic principles of the components
> > they're talking about.
>
> "misled by persuasive idiots.*\.$" Perfectly said.
>
> If one wants to implement a X.509-type CA on top of, or as an alternative
> to,
> the W0T, one is free to do so. Werner has made this point numerous times.
> But
> it will fail if you try to regulate or legislate the keyservers into
> compliance with your scheme.
>
> > The most forgiving interpretation is that you want the server operators
> > to have performed some kind of filtering, but still accept
> > responsibility for trust verification yourself.  This is a recipe for
> > the filtering-by-others being "good enough" for people who don't
> > understand what's happening, and then again we're back to lawsuits when
> > reality shows that the filtering would never be complete.  It would
> > never be complete because there's no true definition of what should be
> > filtered out.  At the most simple level: "Are pseudonyms allowed?"
> >
> > Please, please don't bring laws into this if you want to continue to
> > benefit from a public service provided for free by volunteers.
> >
> We've already lost one keyserver due to someone believing his key could
> somehow be removed from a keyserver and insisting it was his right under a
> national data protection act. The operator was a valued member of the
> community. This incident has with probably led to the loss of patience with
> and the typically blunt application of a cluebat to the removalist camp.
>
> The keyserver network actually works because of the lack of regulation.
> Trying
> to regulate its operation is viewed by many as trying to control who may
> and
> may not use crypto.
>
> I keep seeing arguments being made about trusting the data from
> keyservers. I
> think it is fundamentally naive to think that a [NSA|GCHQ|BSI]-regulated
> keyserver will be considered being more "trustworthy" than what we have
> now.
>
>
> --
> John P. Clizbe                      Inet: John (a) Gingerbear DAWT net
> SKS/Enigmail/PGP-EKP                  or: John ( @ ) Enigmail DAWT net
> FSF Assoc #995 / FSFE Fellow #1797  hkp://keyserver.gingerbear.net  or
>      mailto:pgp-public-keys at gingerbear.net?subject=HELP
>
> Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
> A:"An odd melody / island voices on the winds / surplus of vowels"
>
>
>
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130912/b910112c/attachment-0001.html>