[Sks-devel] Legalese for mismatched expectations

[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-----