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

Jon Callas <jon@pgp.com> writes:

The CMR feature in pgp5.5 isn't so far intented to cope with this scenario I think. That's because pgp5.5 I understand can only generate keys with one CMR request field.

Well, Adam, you are yet again describing it wrong. You can put in N of them. You are right that the 5.5 UI isn't general.

I did understand that even pgp5.0 standard allows multiple CMR keys, but I thought that the pgp5.5 UI doesn't allow generation of keys with more than CMR packet per userid... so sounds like we agree? One thing I never did get clear is: does pgp5.0 know how to reply to the CMR denoted extra recipients?

Also, there's another thing you're not describing correctly. This is not a feature of the key -- it's a feature of the user name, and included in a user name's self signature. It can be changed at any time, and you can even have an ambivalent key that has a username with the CMR packet (salesdweeb@foobar.com) and a without it (jblow@foobar.com).

Excuse me, yes, I have been tending to talk about the CMR being attached to the key, while it is actually attached to the userid, of which there can be many. I tended to view this as a valid simplification, because, if I understood correctly, the pgp5.5 business suite allows an administrator to configure the pgp5.5 client which employees will be using to enforce that there _will_ be a CMR packet on all userids? And also most users are likely to have just one userid. In other words, I am not denying any of the functionality that it does have, in being able to be used in privacy respecting ways, but rather I am describing the most strict settings that the software attempts to enforce if so configured. This is still interesting because one suspects some companies will use it this way, otherwise the functionality wouldn't have been provided.

[...]

This is why any sort of shared or escrowed keys suck. But in most cases it's good enough, because when Fred leaves sales, he loses access to the sales computers.

It's not that good because even though he loses access to the computers, if he retains a copy of the private key, he (or the competitor he has left to join) can fairly easily obtain the ciphertext of emails. Proxy encryption is a good solution to this, if it works for the EG keys you are using. Or super encryption or TLS to protect the company internal multiple crypto recipients. I am not so much against CMR crypto recipients per se, as I am against allowing these to show outside the LAN -- too tempting for governments.

Really it seems to me that actually having half a dozen sales droids sharing a key, or being able to decrypt a message because they are all CMR enforced multiple crypto recipients is a security nightmare either way :-)

Reckon it would be arguably more secure to have the SMTP policy enforcer decrypt it for them, even.

Really? You think the SMTP agent should be decrypting? Wow. I don't.

It clearly could be more secure in some environments, with crypto illiterate users who can't remember good passwords, or who have tendency to write them down. If they're all sharing keys because they're all part of the same sales team, and the traffic is fairly low security, I wouldn't discount it out of hand.

I think that's *really* intrusive, and worse than what we did.

I think that is where we differ ... you focus on privacy principles, and end up having less security and less resistance to government abuse. The above is merely an ergonomics trade off for some environments. It doesn't overly help governments snoop, and can be used where appropriate. You can still have individual personal use keys, or any other privacy respecting architecture. If we were to argue about how systems could be abused (either government or company abuse) CMR could be abused with an enforced CMR key on all company keys, and some software to read all mail before delivery, and approve all mail on the way out. CMR could also be potentially be abused by governments in passing laws saying communications keys must have government as a CMR recipient, and in being able to enforce this by spot checking emails in transit, and/or via deputised ISPs with binding cryptography used to allow untrusted fourth parties to check session keys match.

Interestingly enough, there are a number of people (like Bruce Schneier) who have no problem with the additional encryption part, but think that the SMTP agent is the work of the devil.

The enforcement part of it is :-) Multiple encryption over done with too many long term keys also tends to be a security risk. Basing recovery procedures on storage recovery avoids this trend, and avoids the need to have recovery of communications keys at all for the defined corporate user requirement.

Another method of authenticating TLS is to base the authentication on the user's PGP WoT. Include authentication information to the delivery agent which is capable of TLS, which is also exchanged inside the encryption envelope. (Eg. transfer an authentication symmetric key k1 inside the encryption envelope; send the local TLS capable SMTP hub / SMTP policy enforcer the key k1. The TLS forward secret key negotiation can then be authenticated using this key. The remote TLS system can tack the authentication information on to the delivered message, in a header, or otherwise, and the recipient can check the authentication).

Note that the user's WoT is stored in the user's keyring. There's an operational problem here. This means that the MTA has to have access to all users' pubrings. This is not a good thing, to my mind.

No, I think you misunderstood the above. MUA sends X-MTA-authentication only if the MTA is TLS aware, then it sends: To: fred@acme.com X-MTA-auth: 12345678 -----BEGIN PGP MESSAGE----- blah blah -----END PGP MESSAGE----- the local MTA strips out X-MTA-auth info. Local MTA does a DH key exchange with the remote MTA. Local MTA encrypts with symmetric cipher (say IDEA or something) the hash of DH parameters and negotiated DH key with X-MTA-auth key, and puts back in header: X-MTA-auth: abcd1234abcd1234abcd1324abcd The receiving MTA leaves that alone, but adds a line telling the MUA the DH key hash: X-MTA-key: 567856785678 The MUA hands the X-MTA-auth line to the pgp implementation, together with the encrypted message. You have another packet inside the pgp encryption layer which tells the receiving MUA the sending client's info... and PGP can check the authenticate the DH key exchange after the fact. If there is a MITM you will know about it. Neat because it doesn't require separate key infrastructure which always ends up having less meaning to the user being down at the mail hub level. And yet you have real interactive perfect forward secrecy.

It is possible that there is an unstated perceived user requirement, that the messaging standard be able to allow third party access to the communications traffic directly.

Nope, that's not what we're arguing for.

OK, thanks. I'll stop speculating on that one then.

What we're arguing for is an alternative to key escrow -- the kind where your employer keeps your secret key just in case they need it.

Please read: http://www.dcs.ex.ac.uk/~aba/cdr/ It also avoids key escrow for communication keys, and allows separate personal and company use storage keys, makes recommendations for sender and receiver statement of intent about plaintext handling, has more ergonomic recovery options, and allows more secure more frequent communication key updates. 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`