1997-10-23 - Re: PGP 5.5 CMR/GAK: a possible solution

Header Data

From: jmayorga@netscape.com (John Mayorga)
To: cypherpunks@toad.com
Message Hash: cc09cff2f2a3204196385db80840337a537adc61afcdc14f288e16e17b5db526
Message ID: <344E929C.EED741BF@netscape.com>
Reply To: <3.0.3.32.19971022113904.00bca690@mail.pgp.com>
UTC Datetime: 1997-10-23 00:07:27 UTC
Raw Date: Thu, 23 Oct 1997 08:07:27 +0800

Raw message

From: jmayorga@netscape.com (John Mayorga)
Date: Thu, 23 Oct 1997 08:07:27 +0800
To: cypherpunks@toad.com
Subject: Re: PGP 5.5 CMR/GAK: a possible solution
In-Reply-To: <3.0.3.32.19971022113904.00bca690@mail.pgp.com>
Message-ID: <344E929C.EED741BF@netscape.com>
MIME-Version: 1.0
Content-Type: text/plain

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, 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)







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: jmayorga@netscape.com
tel;work:       4556
x-mozilla-cpt:  ;0
x-mozilla-html: FALSE
version:        2.1
end:            vcard





Thread