1997-10-17 - Re: what can we do about PGP sell out and CMR?

Header Data

From: Bill Stewart <stewarts@ix.netcom.com>
To: Adam Back <tcmay@got.net
Message Hash: 96a7569ac2c4ff2703359cdbf4b1765925930ea941e01643856651267b823b6e
Message ID: <3.0.3.32.19971016084223.006c0bf0@popd.ix.netcom.com>
Reply To: <v03102801b06ac04e5a12@[207.167.93.63]>
UTC Datetime: 1997-10-17 07:58:08 UTC
Raw Date: Fri, 17 Oct 1997 15:58:08 +0800

Raw message

From: Bill Stewart <stewarts@ix.netcom.com>
Date: Fri, 17 Oct 1997 15:58:08 +0800
To: Adam Back <tcmay@got.net
Subject: Re: what can we do about PGP sell out and CMR?
In-Reply-To: <v03102801b06ac04e5a12@[207.167.93.63]>
Message-ID: <3.0.3.32.19971016084223.006c0bf0@popd.ix.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain



At 11:29 PM 10/15/1997 +0100, Adam Back wrote:
>From Bill Stewart's report, given the apparent amount of effort PGP
>have put into their CMR based enforcement policy functionality, I
>predict they won't remove CMR whatever we, or Schneier, or anyone else
>says or proves about more secure less GAK-friendly ways of

They've got customers who wanted it; there's some room for making
it less controllable within their current framework (e.g. making
the behaviour for (as-yet unused) multiple CMRKs to be 
session-key-splitting rather than one-copy-per-CMRK, which is
be the more obvious implementation and is far more GAK-friendly.)

Also, the SMTP filter stuff won't go away - even if PGP Inc
dropped the product and dropped the CMRK from PGP 5.5.1 and
all future versions, once there's an API for PGP,
it's a piece of cake to write one; 
you just don't get the visibility that some keys are CMRKers, 
and you've got the inconvenience of sending more bouncegrams to 
senders telling them "to send a copy of PGP-encrypted mail to Bob,
you need to also encrypt it to Eve The PostMistress" or, 
less honestly, "... to the Exchange Gateway".
And at least the PGP SMTP filter only checks for the KeyID and
doesn't actually try to deccrypt the message.

>I also suspect they won't 
>listen to Tim's earlier argument that they do nothing about recovery

I thought Tim's point was directed to OpenPGP; Jon Callas and others
said things like ~~If you've got features you want done, 
propose it to OpenPGP and get them to adopt it, and that'll
give us a business reason that we ought to adopt it.~~
(I think the context of that was discussing Stealth, which they
still don't have enough business demand for to take time on,
and which by the way puts a major crimp in SMTP filters.)

>This quote should give us clue as to why they will continue with CMR: 
>	"we're a real company with accountants"

That wasn't an exact quote, just a paraphrase from my memory of 
several conversations.  

>Similar arguments would presumably present them with "no choice" but
>to fulfill the order for 100,000 GAK compliant units from the
>government terrorizing the freedom fighters PRZ likes to tell us
>about who are already using PGP GAK compliant software: pgp5.0.

Even if they did that, it wouldn't change the power relationships;
if the government can compel GAK keys by filtering SMTP or
confiscating non-eavesdropping-compatible mail gateways,
it doesn't matter if the Cc: Big Brother was added as a PGP5.5 CMRK
or as a PGP2.6.2i multiple recipient - you can't tell from
the message format (except for DH vs. RSA).


>What can we do about this situation?  Well we could build systems
>which hack around the CMR system.  Easy enough: just put dud
>"recovery" info inside.  We still have deployment problems.

Unless I misunderstood the formats, 
CMRKs are just identified by KeyID, not by fingerprint,
and it's easy to look through the public keyservers to find CMRKs
(though companies may prefer to have their employees mail out
keys to people who need them rather than making all their
keys constantly visible on the outside servers.)
So go find them all, send protest email to the postmasters
and corporate officials at the companies that use CMRKs,
crank up your deadbeef generator to make your own keys
with the same KeyIDs as the CMRKs, and pre-load the public keyservers.
A nice touch would be to burn your copies of the private keys
for the CMRK imitators, but we'll never know if you did, will we?
				Thanks!
					Bill
Bill Stewart, stewarts@ix.netcom.com
Regular Key PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639






Thread