[Sks-devel] Legalese for mismatched expectations

2013-08-30 Thread Phil Pennock
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

The world is changing, more people are trying out security technologies,
and if you think many people using PGP before didn't know what they were
doing, I think the next couple of years will drive a few more PGP folks
to drink.

One issue that arises is that as the userbase of a product shifts, and
their expectations of what the product provides shift, assumptions which
were fine before might stop being fine afterwards.  A lot of people now
want to have security, for free, with no understanding, and have it
somehow be PRISM-proof.  As someone in the USA who runs a PGP
keyserver for the general public, I need to take reasonable steps to
make sure that I convey clearly what a keyserver does or does not
provide for the people using it.

As a first step, earlier I updated the text on
http://sks.spodhuis.org/ with a new third paragraph, in HTML strong,
pointing out some security implications.  I probably need to find time
to mess with fonts to not have my CSS tell folks to use a font where
strong isn't very strong.

Here's what I came up with:

  Note: this service is provided free, to the public, in the hopes that
  it might prove useful. No warranty is provided, nor any offer of
  continuing service or access. By using this service, you MUST
  understand that presence of data in the keyserver (pools) in no way
  connotes trust. Anyone can generate a key, with any name or email
  address, and upload it. All security and trust comes from evaluating
  security at the “object level”, via PGP Web-Of-Trust signatures. This
  keyserver makes it possible to retrieve keys, looking them up via
  various indices, but the collection of keys in this public pool is
  KNOWN to contain malicious and fraudulent keys. It is the common
  expectation of server operators that users understand this and use
  software which, like all known common OpenPGP implementations,
  evaluates trust accordingly. This expectation is so common that it is
  not normally explicitly stated.

Perhaps others can improve upon this.

- -Phil
-BEGIN PGP SIGNATURE-

iEYEAREDAAYFAlIhMW4ACgkQQDBDFTkDY38rWgCcDVJ7i/wCvJyoX9DgoVp6utFA
A7MAn26C5K2TYNjs3oR/texosvG7kQm0
=IpKy
-END PGP SIGNATURE-

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel


Re: [Sks-devel] Legalese for mismatched expectations

2013-08-30 Thread Jeffrey Johnson


On Aug 30, 2013, at 7:57 PM, Phil Pennock sks-devel-p...@spodhuis.org wrote:

 Perhaps others can improve upon this.

Too many words, keep it KISS in plain speak.

Say what you just said in, say, 3 sentences using no more than 5
commas.

JMHO

73 de Jeff
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel


Re: [Sks-devel] Legalese for mismatched expectations

2013-08-30 Thread Christoph Anton Mitterer
On Fri, 2013-08-30 at 20:46 -0400, Jeffrey Johnson wrote: 
 Too many words, keep it KISS in plain speak.
Agreed...

First, it's not our job to educate people with respect to
cryptography/security in general... we should only focus on the
keyserver related issues, and as such we should IMHO rather try, to
educate users that the whole keyserver network can never really protect
from MiM downgrading and/or blocking attacks.
But even that should be rather educated by the OpenPGP implementations.

A simple note as in the BSD license, that the service is provided as
is, might make sense, though.



Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel


Re: [Sks-devel] Legalese for mismatched expectations

2013-08-30 Thread Phil Pennock
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

On 2013-08-31 at 02:57 +0200, Christoph Anton Mitterer wrote:
 On Fri, 2013-08-30 at 20:46 -0400, Jeffrey Johnson wrote: 
  Too many words, keep it KISS in plain speak.
 Agreed...

If I were smart enough to include the needed information in fewer words,
it would use fewer words.  Explicit suggestions appreciated, but needs
to be shorter is kind of obviously true.

 First, it's not our job to educate people with respect to
 cryptography/security in general...

It might not be our job, but in the jurisdiction I live in, there are
nasty concepts like attractive nuisance, where you can be minding your
own business, avoiding putting up barriers, and when someone else gets
in trouble through their own mistakes, you get in trouble for having a
garden without secure fences.

That's just the most obvious analogy; in the USA, there are all sorts of
nasty ways that providing a public service to others can leave you
legally exposed to the consequences of someone's ignorance.

When experts say surely nobody could blame us, judges say it's your
fault.  Especially if the experts can be painted as remote robots and
it's an election season (since many judges are elected too).

So, I am absolutely going to have warning text, even if it's not my
job to take responsibility for the ignorance of others.

- -Phil
-BEGIN PGP SIGNATURE-

iEYEAREDAAYFAlIheiQACgkQQDBDFTkDY3/DhwCfUQO3TkOjeDGZjWyic8k8KmvH
GRIAn2KHXiTAZzG+PghpwjOZxCJtwDac
=atH9
-END PGP SIGNATURE-

___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel