[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PGP 5.5 CMR/GAK: a possible solution
This whole "company key", "department key", and "personal key" business seems
strangely similar to the hierarchical structure of an LDAP server. I wonder where
we could store that information... :-)
Just my 2�.
John E. Mayorga
Jon Callas wrote:
> At 03:02 AM 10/22/97 -0700, [email protected] 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
> <[email protected]>', 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 [email protected]
> 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)
begin: vcard
fn: John Mayorga
n: Mayorga;John
org: Netscape Communications Corp.
adr;dom: ;;501 E. Middlefield Road, Mountain View, CA 94043, USA;9;;;
email;internet: [email protected]
tel;work: 4556
x-mozilla-cpt: ;0
x-mozilla-html: FALSE
version: 2.1
end: vcard