From: Jon Callas <jon@pgp.com>
Date: Thu, 23 Oct 1997 02:58:27 +0800
To: cypherpunks@toad.com
Subject: Re: PGP 5.5 CMR/GAK: a possible solution
In-Reply-To: <877514566.20581.193.133.230.33@unicorn.com>
Message-ID: <3.0.3.32.19971022113904.00bca690@mail.pgp.com>
MIME-Version: 1.0
Content-Type: text/plain



At 03:02 AM 10/22/97 -0700, mark@unicorn.com wrote:
   
Thanks. I want to add that what's in 5.5 is hardly what we think is
perfect. The system is designed simply to be preferable to key escrow. We
have some improvements we're planning for it in the future. So you're right
-- it's a short-term solution.
   
   The current system sends out a user's personal key, with a tag to say that
   if I don't encrypt to the company as well, my mail will bounce. But think
   about this: how often do I want to send email to a particular person in a
   company, and ensure that only they see it? And how often do I want to send
   mail to a particular group inside a company? All I want is to ensure that
   I get a response from the company, I usually don't care who I talk to in
the
   process.

You have it mostly right. There's a tag in a self-signature that says,
"please encrypt to this other key, too." The only time you are required to
encrypt to Alice's other key is if you and Alice share the same additional
key (and not always even then).
   
   So PGP's "everything private unless you choose to make it public" system
   seems backwards. Surely what we really need to meet these customer demands
   is an "everything public (within the company) unless you choose to make it
   private" system? That is, all mail to my department inside the company
   should be encrypted to a department key, shared by all members, *unless*
   it is confidential, in which case it should *only* be encrypted to me. 

This is certainly possible with the system, and in fact easier to implement
than anything else.
   
   Here's how I see this working: when Joe Blow joins Foo-Bah Cryptosystems,
   he creates his own personal PGP key. He also gets a copy of the department
   key, which he can use to decrypt any mail which is encrypted to his
   department; or this decryption could be handled automatically by a
   department email server to ensure that individuals never have access to the
   department's private key. PGP then creates a public key for 'Joe Blow
   <joe.blow@foo-bah.com>', which would be the department key with a signed
tag
   linking it to his personal public key. This is the tagged corporate public
   key which he would give out to any customers. 
   
   When a customer wishes to send email to Joe, he would use this public key.
   When encrypting, PGP would detect the tag and put up a dialog box pointing
   out that this is a corporate key and if they click on the 'confidential'
   button it will be encrypted to the user's personal key prior to encrypting
   to the corporate key (by which I mean superencryption, to avoid traffic
   analysis). The default would be not to superencrypt; and as a side effect
   this system would be compatible with any version of PGP for
   non-confidential mail (assuming that version understands the encryption
   algorithms in use). 
   
   The effect of this is that if someone wants to send email about an urgent
   bug and I'm out at lunch, any of my co-workers can read that mail. But if
   they want to send *me* mail about confidential inter-company negotiations,
   the co-workers could decrypt the outer layer of the message, but would be
   blocked by the inner layer encryption to my personal key. 
   
   As I see it, this system is simple, solves the problems which PGP claim
   they need to solve without creating the snooping problems Tim and others
   have discussed, cannot easily be adapted to GAK ('This message is to be
   encrypted to the FBI public key. If it is confidential, click here to
   superencrypt to the recipient's personal key'), and won't require a
   massive change to the PGP source code. 

This is exactly CMR. The only thing that Business 5.5 does is automatically
add the department for you, and put up the recipient dialog so it can be
taken off. Congrats.
   
   There are some obvious security issues with having the department key
   shared amongst the members of the department, but I don't see that they
   are any worse than PGP's current CMR implementation, which has already
   discussed the use of department keys; it's certainly better than using
   plaintext. There are also problems with encrypting confidential mail to
   multiple recipients, but they're surmountable; an easy solution, if you
   don't care about traffic analysis, is to only encrypt confidential mail
   to the personal key rather than superencrypt with the corporate key. In
most 
   cases such mail wouldn't be sent to multiple recipients anyway. 
   
   So here's how I'd see the simple system working:
   
   A PGP CMR key would consist of
   
   1. A corporate key; this might be company-wide, department-wide, or
      an individual escrowed key; this choice is a seperate key-management
      issue for the corporation.
   2. Optionally a personal key, which could only be decrypted by the
      individual.
   3. A signature from the corporate key linking the personal key to it
      and the specified User Id.
   4. Optional flag to indicate which key to encrypt to by default.
   5. User Id, signatures, etc
   
   When PGP was asked to encrypt to such a key, it would check for the
   optional personal key. If it wasn't there, it would put up a warning
   box to tell the user that the message can be read by people other than
   the recipient. If it is, then it would put up a dialog box allowing the
   user to choose whether to encrypt to the corporate key or the individual
   key, normally defaulting to the corporate key. This system could not easily
   become GAK because it will only encrypt to one of the keys and not both;
   the FBI could create FBI CMR keys from all our public keys, but then PGP
   would either encrypt to the FBI and I wouldn't be able to read it, or
   encrypt to me and the FBI wouldn't be able to read it.
   
   Anyone care to pick any holes?

Looks good from here. You've redesigned PGP 5.5. Thanks.

	Jon



-----
Jon Callas                                  jon@pgp.com
Chief Scientist                             555 Twin Dolphin Drive
Pretty Good Privacy, Inc.                   Suite 570
(415) 596-1960                              Redwood Shores, CA 94065
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)