Marc Grant
stewarts@ix.netcom.com wrote:
Not true - you can't implement CMR without a mail enforcer unless you can stop your employees from using non-CMR versions of PGP, which is nearly impossible.
No, you can't enforce corporate snooping without a mail enforcer. You can meet the corporate demands which PGP claim to be supporting without a mail enforcer. There's a difference.
The only real benefit of CMR over the alternate systems suggested is that the corporation can snoop on all email sent to their employees.
You can build more secure alternatives even for corporate mesage snooping. Key escrow is better, or placing proxy keys on the server to convert a copy of the message to the company snoop key.
Yet PGP Inc have claimed on several occasions that this is not their intention. Odd, that.
One PGP employee explained the perceived user requirement:
Scenario #1: employee is away from desk (holiday, out of office, off
sick) and mail arrives which is marked URGENT -- what now?
Scenario #2: employee quits jon in a huff, refuses to divulge
passphrase, lots of queued encrypted email -- what now?
Scenario #3: employee dies, lots of email queued, what now?
Well some people have argued that it's not a big deal, just get the
sender to re-send encrypted to a different person.
Whatever. Anyway the argument against CMR is not that it allows
companies to read employees mail when addressed to a company use email
address encrypted to a company use key -- that seems reasonable
enough for some applications.
The problem with CMR is that it's a) a security flaw, b) it is open to
abuse by governments.
Scenario #4: user forgets passphrase
which is arguably the most likely and frequently occuring failure is
badly addressed by PGP Inc with pgp5.5 -- the key is lost. Their
recovery from this failure is to generate a new key, and have the
company decrypt anything which needs to be read. This is messy
because encrypted materials can be scattered everywhere (they use the
same key for storage as for email)... on the disk, write once CD
archives, tapes, inside ZIP archive files, etc. And to do the job
properly all of these need to be decrypted by the corporate recovery
czar and re-encrypted to the users new key.
Simplest solution is simply to have a copy of the users key, or store
a copy on the disk in a form the recovery agent can recover ready for
the user to type in a new passphrase.
You can still have separate personal use keys -- the user forgets the
passphrase for these at his own peril and has his own backup mechanism
(copy written down at home hidden somewhere, or whatever, or simply
not recoverable at all).
And signature keys should not be recoverable -- generate a new one and
have it re-certified.
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