From: Marc Horowitz <marc@cygnus.com>
Date: Wed, 11 Jun 1997 05:22:39 +0800
To: Bill Stewart <stewarts@ix.netcom.com>
Subject: Re: Access to Storage and Communication Keys
In-Reply-To: <Bill Stewart's message of Mon, 09 Jun 1997 00:09:38 -0700>
Message-ID: <t534tb6f9w4.fsf@rover.cygnus.com>
MIME-Version: 1.0
Content-Type: text/plain



Bill Stewart <stewarts@ix.netcom.com> writes:

>> An interesting perspective, but I don't know that it works.
>> For this to make sense, either the business needs to have access to
>> the stored received email if the user gets run over by a police car,
>> or else the business needs to know that it doesn't _need_ access -
>> either because the mail isn't business related, or because the
>> business-related parts have been transferred to other systems
>> using a convenient user interface.

It is impossible to know if a given email is business related or not
automatically.  Probably the best idea is to have my business email
key escrowed (by my MIS department, not uncle sam!), but to have my
personal email key not escrowed.  Probably, I want to use two
completely different email addresses.  This does require that the
sender use the correct address and key when sending me personal email.

I do believe that there is a case for private key escrow here.  Some
of you will say that the sender should just encrypt the message to me
and to the MIS message-escrow key.  This is ok, too, but it still
requires that the sender remember to do this for business email and
not for personal email, so you've just changed the nature of the
burden slightly, not removed it.

>> >The *only* reason to escrow communications keys is to spy on people;
>> >there is never an opportunity for data loss here.
>>
>> Yeah!  (Actually, the other reason to escrow them is because
>> you're using the same keys for communication and storage,

This sort of thing is where we as cryptographic engineers need to keep
on our toes.  If we never use the same key for communications and
storage encryption, this issue never comes up.

>> of storage keys, but that's only the case if you're not using
>> a sufficiently flexible cryptosystem and are using key backup
>> instead of data backup, which is really the preferred approach anyway.)

Key backup is far more practical than data backup in a large
environment.

ObCryptoIdea: a backup system which lets me set a public key
associated with my directory/disk/whatever.  The backup system will
encrypt the backup in a symmetric key encrypted by this public key.
If a restore is needed, the backup system and I engage in a dialog to
disclose the relevant symmetric key.  For mission-critical data, the
public key must come with a certificate indicating that the private
key has been escrowed, so that if I get hit by a truck, the data can
be recovered.  For personal data, I keep the private key to myself.
This means that I can have the safety of knowing my data is being
backed up, but I never have to worry about archives of my data coming
back to haunt me (unless the company/school/ISP is malicious and keeps
it's own records of the symmetric keys, but then I'm screwed in any
case).

		Marc