From: Bill Stewart <stewarts@ix.netcom.com>
Date: Thu, 9 Oct 1997 12:45:06 +0800
To: Jon Callas <minow@apple.com
Subject: Re: What's really in PGP 5.5?
In-Reply-To: <3.0.3.32.19971007142710.00a22970@mail.pgp.com>
Message-ID: <3.0.3.32.19971008213456.006ae340@popd.ix.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain



At 02:27 PM 10/07/1997 -0700, Jon Callas wrote:
>When I was at HIP97 this August, I was amused to hear cypherpunks
>chanting, "Data recovery good, key recovery bad." 
...
>The essence of data recovery is that focusing on the keys is a canard. 
>If you've misplaced your data, you want the data back, not the keys.
>The only people who want your keys are people who want to spy on you. 

Eric Hughes brought up this at a cypherpunks meeting earlier this year.
It doesn't mean that businesses often _need_ data recovery, 
and there are serious and complex concerns about 
	"what data do we keep?  what data do we discard?"
that companies, their legal staffs often deal with.
In particular, the Intellectual Property Bureaucrats tend to get
very concerned if you either do or don't have a large collection of data
in one place, as lawsuit targets, conflict of interest between departments,
and "simultaneous employment" opportunities for clerks and computer-janitors.
But it's clearly the case that they don't need keys, only maybe data.
I haven't yet seen a technical description of PGP5.5, but it sounds like
it's implementing copying data to some corporate data-escrow key.
Note that, while it is a lawsuit/subpoena/warrant target,
that's typically not something that happens without company knowledge,
unlike Louis Freeh's dream of no-knock backdoors for your data.

So who gets the data?  How do you tell what kinds go to whom?
Any corporate feature for implementing this needs to provide some
mechanism and interface for supporting multiple alternative recipients -
if you need message escrow, you may need the 90-day-Work-In-Progress escrow,
or the Long-Term-Projects escrow, or the Company-X-Relationship escrow, 
or the Accounting-Department Escrow, or the Retain-for-Legal-Department escrow 
- note that these are different functions from just copying those recipients,
because an escrow feature is supposed to be semi-automatic and not for
automatic and convenient access.  

Doing the job right really means you need to be able to send mail to 
recipients who get only a secret-shared slice of the session key, 
not the whole thing - not only for corporate data escrow, but also for
mail you've addressed yourself that goes to your lawyers, or the
managers of your trust, or the three trustees of your corporation.

>One of the downsides of cryptography is that if you lose your passphrase
>(or token, PIN, smart card, or whatever), you've lost your data. 

One way to help this problem is to support secret-sharing for user key backup,
as well as the ability to make copies of keys with different passphrases
(e.g. the floppy in the offsite-storage with the passphrase on the yellow-sticky
doesn't use the same passphrase as the same key on your desk machine.)

>(5) The system has to allow someone under a legal threat to respond
>effectively to that threat. Legal threats include warrants, subpoenas, and
>discovery processes. You have to be able to respond to the request for
>information without losing your keys and thus all of your data.

This is an important point - if you've got [data  + session key] escrow,
you've got a reasonable court case that says the court doesn't need your 
master keys, just the keys for the specific messages.  Of course,
they _can_ ask to see _all_ the messages by the targeted senders,
just as they can ask to see all the paper in your file cabinets,
but you at least have some ability to fight it.

>(6) It must also provide a response to those who would regulate crypto in
>the name of public safety. Fortunately for us, potential regulators have
>focused on the horsemen of the infocalyse. 

The issue of whether this is in fact needed or if it's giving in to
the Great Satan is of course the critical one....

> A few weeks ago, we showed it to the FBI and asked their opinion.
> They told us it doesn't meet any of their needs.

No, No, Br'er Zimmermann, Don't throw me in that there briar patch!


				Thanks!
					Bill
Bill Stewart, stewarts@ix.netcom.com
Regular Key PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639