Mark Grant <mark@unicorn.com> writes:
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.
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. What you're describing is an alternate use for CMR: to allow sales@acme.com to have attached to it the request that messages to that address be encrypted for all the sales people. Well that seems reasonable in a way. Still potentially dangerous in that the NSA will soon enough be asking to be on every one's CMR list. (As far as I can tell the next version (pgp6.0 or whatever) will include capability to create keys with multiple CMR requests. The capability to handle them is already in pgp5.5 by all accounts.) The other alternative is as you say: to have group keys which are shared amongst the sales people. There are problems with this in managing the secure distribution of the shared key: sales manager creates it, and emails securely to all sales team members? Plausible I suppose. 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). 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. Another option would be Matt Blaze's proxy encryption. That allows the owner of the sales@acme.com key (perhaps the sales manager) to create proxy keys which can convert messages addressed to sales@acme.com into messages addressed to fred@acme.com, jane@acme.com, and the rest of the sales droids. (I thought Dave Wagner came up with an example of a public key proxy function for an RSA or El Gamal variant or something). With proxy encryption you still have to have the proxy keys somewhere, but you could keep them out of Fred's hands by putting them on the SMTP policy server for it to convert incoming traffic. This seems to be more secure than either approach. And avoids the security risk of having multiple long term encryption keys used to allow access to communications traffic. That way at least messages aren't coming over the wire addressed to 101 people. And also you don't have to worry so much about quick propogation of revocation certs. And when someone leaves you can remove their proxy key from the SMTP server. The whole problem is really quite complex, and there are no easy solutions to group secured mail access where people are leaving and joining the group at short notice. Proxy cryptography seems to add something quite useful to this mix. Some form of transport level security adds something to the mix also, because then if you are using CMR keys, or even normal pgp2.x multiple recipients, or you are using long term encryption keys (as PGP Inc seems to be currently recommending with pgp5.x (recommended validity setting of `forever')) at least old traffic isn't directly vulnerable. Several people commented on using a forward secret TLS between SMTP servers opportunisitically (if the SMTP server supports the extension, then use it; if not fall back to current situation). Even without any authentication, this is a win because the main threat from government is massive eavesdropping and key word scanning, or saving of targetted users mails for later key compromise. Unauthenticated TLS still forces the attacker to use active attacks. Authentication can be added later as part of IPSEC/IPv6 key infrastructure. 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).
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. Your description is another plausible permutation also, I think, which has it's own merits and security/privacy/political abuse trade-offs. 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`