From: Adam Back <aba@dcs.ex.ac.uk>
Date: Sat, 11 Oct 1997 11:29:14 +0800
To: jon@pgp.com
Subject: Why Jon Callas keeps picking nits (Re: Why Corporate Message Recovery isn't Key Escrow)
In-Reply-To: <3.0.3.32.19971010145353.00ad9330@mail.pgp.com>
Message-ID: <199710110112.CAA06510@server.test.net>
MIME-Version: 1.0
Content-Type: text/plain




Jon Callas <jon@pgp.com> writes:
> A number of people have asserted that the Corporate Message Recovery
> feature is key escrow. From where I sit, the difference is easy to
> see. My definition of "key escrow" is that another person or
> organization keeps a copy of the user's secret key.

You are adopting a narrow technical meaning of key escrow.  Key escrow
also has another meaning in common parlance: third party access to
communications.  Now I know this common parlance isn't technically
accurate, but "key escrow" itself is a piece of newspeak, a clever
term coined by secret service / government spin doctors.  It has
entered the language like it or not (I don't like it).  This common
parlance meaning is probably more widely understood and used than the
technical meaning you are using.

With that in mind, you may start to see why people, such as Schneier,
and others over the last few days have been telling you "you're
picking nits".

Point is pgp 5.5 allows other people to have access to your
communications.  Your SMTP policy enforcer even attempts to enforce
this.  You also described a feature whereby an administrator could
remotely configure and restrict functionality in pgp 5.5 mail client
(I am unclear as to whether this allows the admin to enforce snoop
access or not).

Your own term CMR (Corporate Message Recovery) isn't that accurate a
description itself, it's a bit of a euphamism at best.  What you're
recovering is transient communications which don't need recovering
anyway.  What PGP is really up to is enforcing capability for
Corporate Message Snooping.

[line breaks were _all over_ the shop, I've reformatted]

> Here's an example, based on actual customers who use key escrow to
> manage their data:
> 
> This corporation uses PGP for a number of things. Email, engineering
> plans, CAD drawings, and so on. They've done so at least since the
> days when we were Viacrypt, and I believe they even used PGP 2.x.

First point, which I'm getting bored of repeating: keys have different
uses.  Storage keys, transient communications keys, signature keys.
You're using one key for all 2 functions; that is the root of your
problems and dilemmas.  You're using what should be a storage key to
receive transient communications, then you're proceeding to wonder why
this causes you to have the undesirable situation of having a GAK
compliant system (or more properly trying and failing to argue that
you don't have one).

> When an employee arrives at this company, they create a key pair for
> the new employee, hand it to them on a floppy, keeping a duplicate
> floppy with the keypair on it, which they toss into a
> safe. Literally. This is key escrow.  They do this because they
> can't afford to lose their files and messages. Their policies
> require them to keep the secret keys, as if they were the same as
> keys to offices or file cabinets.

You know, what they're doing: it's not so bad for data encrypted on
their disks.  They can acheive the departmental level escrow to
distribute risk just the same with this form of escrow.

You don't need to escrow transient communications keys at all anyway.

Your pgp 5.5 isn't going to help recover the actual data of value, all
those stored CAD files...  You know why?  Because they're on the disk,
not in transit in the email system.  So you haven't solved the claimed
problem.

If you want to do something about the claimed problem work out some
secret splitting solutions to better distribute trust for escrowed
storage keys.  (Now this is a real use for escrow: the company is safe
guarding it's own encrypted data on disks and tapes for it's own
benefit).

> - From our standpoint, the issue gets even touchier. They don't like
> what they're doing, and they want us to give them a better way to
> manage their data. Does anyone really believe that only moral
> response is to flinch and turn away?

Nope, your responsibility should be to solve their problems.  (Which
as I show above you have not done.)  Actually your responsibility to
live up to the reputation PRZ transfered to PGP Inc dictates that you
should also do what you can do not build systems which help GAKkers.

Instead your responsibility appears increasingly to produce systems
which smooth the way for coming mandatory GAK by implementing systems
which are GAK ready.

Or if you deny that one, at least you are weakening your
communications security for practically no gain.

> I'd like to be in a situation where I didn't have to deal with
> this. Wanna trade positions? 

Yeah, OK, you don't seem to be managing very well :-)

(Sorry, you asked for it.  I don't actually mean to be rude, I would
just like to get the points across, and to influence PGP to recover
gracefully from this tactical and reputational mistake.)

> It isn't so with a CMRK. The worst possible way to use the feature
> is to have a single, company-wide CMRK. If that gets lost, the
> thriller you can write isn't nearly as interesting. Yup, you can
> steal any of the plans, read all the mail, and so on. That's
> bad. It's deplorable, actually. But it isn't a difference that makes
> no difference. At least there isn't a gang of keys out there that
> can sign anything with anyone's ID.

This is why I was asking above about separate signing keys.  They
surely don't need to stick the signature keys in the safe!!!  In fact
it is counter-productive even for hard-nosed corporate lawyers, and
$$$ driven scruple-short company execs: if they can't prove an
employee penned something they can't use this to prove a case against
him.  If they've got a copy of the signature key, they can forge
signatures which makes signatures useless in litigation involving
company and employee.

> This is not the only way to use Corporate Message Recovery, it's
> just the worst way. Remember, it's just a notation in the
> self-signature that states, "When you encrypt to me, encrypt to X."
> That's any X. You can have a different CMRK for every department,
> every workgroup, or even every user.

It's all screwey because you've got key functionality which belongs in
different keys mixed up.

You should have 3 types of key:

1. signature keys
2. transient encryption keys
3. storage keys

The signature keys you never escrow.  You certify.  If something goes
wrong you re-issue, release revocation cert, and re-certificate.

The transient encryption keys are for communications, you delete them
immediately after use.  Yes I'm talking forward secrecy here.  If you
don't like forward secrecy, well at least don't escrow the encryption
keys.

Storage keys you make damn sure you can recover.  You escrow these for
real.  Company safe sounds about right.  Secret splitting could be
nice also.

> The significant improvement that PGP's web of trust has over a
> traditional hierarchical system is that you can set up a top-down
> system for validity, but you don't have to (and in our opinion,
> shouldn't). Analogously, the significant improvement that Corporate
> Message Recovery has over key escrow is that you can tailor a
> recovery system to your needs (including and especially deciding
> it's not for you).

There is no advantage; the systems are approximately equivalent in
flexibility of architecture.  You can acheive the exact same
architecture with key escrow; just escrow the keys with your backup
czar.

You shouldn't be recovering transient messages, you should be
recovering stored data.

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`