1997-10-15 - fallacy alert!

Header Data

From: Adam Back <aba@dcs.ex.ac.uk>
To: nobody@REPLAY.COM
Message Hash: 4ca1dc91358ea20f730d63315713b5b9a3b392eda9ba9b89078f4b178b9b8e08
Message ID: <199710152321.AAA01692@server.test.net>
Reply To: <199710152145.XAA20388@basement.replay.com>
UTC Datetime: 1997-10-15 23:52:09 UTC
Raw Date: Thu, 16 Oct 1997 07:52:09 +0800

Raw message

From: Adam Back <aba@dcs.ex.ac.uk>
Date: Thu, 16 Oct 1997 07:52:09 +0800
To: nobody@REPLAY.COM
Subject: fallacy alert!
In-Reply-To: <199710152145.XAA20388@basement.replay.com>
Message-ID: <199710152321.AAA01692@server.test.net>
MIME-Version: 1.0
Content-Type: text/plain




Anonymous writes:
> I thought that was the whole point of the PGP design.  It makes the
> presence of third parties clear and visible to all participants.  This
> seems to be the fundamental principle.

I have noticed serveral PGPers use this fallacy also.

It is a fundamental irrelevance.  If PGP Inc has selected this
principle as a guiding principle then they're nuts.

It matters not one whit what `statement of intent' you mark PGP CMR
extended public keys with.  That statement is semantically meaningless
as a design principle because it is utterly unenforceable.

Here are two examples to show how your expectation can be broken:

- the user decrypts your message encrypted to a `company access' key,
  and then proceeds to post it to cypherpunks

- you send a message encrypted to a `company access' key, but the
  company screwed up and lost the private half of the company access
  key

In neither case is the statement of intent honoured.  There are lots
of other ways to not honour such statements of intent, such as perhaps
forwarding a copy to your own supervisor at your company, or printing
out on paper and giving to secretary to file for future reference.

> PGP is designed to allow Alice and Bob to be informed if third party
> access is built in.  Key escrow and re-encryption are inherently
> less visible forms of message access.

re-encryption and forwarding tends to be GAK pervertable, it violates
design principle 2 as explained in corollary 1 of the anti-GAK
principles.  Do not do this.  (I didn't realise the full danger of
this construct until recently, and is one result which fell out of the
exercise of developing a codified set of design rules to guide
protocol designers away from building GAK-compliant or GAKker-useful
software).

"Key escrow" is too perverted a term to know even what you are
referring to.

If you mean data recovery (my CDR proposal) it is _exactly_ as visible
as CMR.  You can affix all the statements of intent you like to it.
(For all the good it will do you.)

There can be no enforcement of statement of intents.  All you can do
is hope that companies are not lying; encourage them to behave in ways
which you consider ethical.

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`






Thread