The current system sends out a user's personal key, with a tag to say
At 01:46 PM 10/22/97 +0100, Adam Back wrote: Mark Grant <mark@unicorn.com> writes: 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.
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. Something had to slip. 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). Problem for both approaches is re-keying: what happens when Fred leaves the sales team to work for a competitor. Revoke the shared key and start over? Or with the CMR method, revoke just the CMR request for Fred, and allow key servers to remove CMR requests when presented with a suitable CMR request revocation cert? (How often will senders check key servers for revocation certs?) Or have short expiries on encryption-only keys (one per day?), so that they key update happens soon enough anyway. (pgp5.x allows for short lived encryption keys directly because of the separation of signature and encryption keys, the WoT applies to the signature key). 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. In most of these cases, when someone decrypts something with the sales key, it ends up going into the order system in plaintext anyway. However, one of the features of the new PGP key format is that you can change encryption keys easily. If you 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. I think that's *really* intrusive, and worse than what we did. 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. Expect pushback. 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.
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.
I think what PGP are arguing for is ability to recover stored messages even if they are intended for one recipient only. As I think has been established this can be acheived by storage recovery, without exposing communications traffic to the associated risks. 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. 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. 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)