On Thu, 8 May 1997, Kent Crispin wrote:
Unfortunately, it doesn't solve the problem at all. In fact it doesn't even address the problem. So much so that reading these replies makes me think that I am looking at different problem than you.
There are many similarities between your idea of a "key safe" for CAK (corporate access to keys), and the idea espoused by Carl and others of encrypting everything to a corporate key as well as to the other recipients. If the corporation expects to be successful at forcing it's staff to run special software that talks to the CAK key safe, then the corporation should also expect to be successful at forcing its staff to run special software that adds the special coprorate key as a recipient of all encrypted messages. If the corporation expects to be successful at keeping the keys to the CAK key safe secure, while still allowing an appropriate coalition of high level managers to get access to the contents of the key safe, then the corporation should also expect to be successful at keeping the private part of the corporate key secure, while still allowing an appropriate coalition of high level managers to use the special corporate private key to decrypt messages. If the coproration trusts those with access to the CAK key safe not to abuse their access, then the corporation should also trust those with access to the special corporate key not to abuse it.
With this background, perhaps now you can see why I say that Carl's solution doesn't even address the problem. The problem is management of complexity. Carl says "encrypt to Acme Corp". Who in Acme Corp? What part of the organization that is Acme Corp is authorized to know this particular bit of information?
Whatever the answer to the latter question is, it's the same in the CAK case as it is in the "encrypt to a special coprorate key" case.
Because some of the employees are idiots you want this built automatically into the application they are using for encryption/email/whatever. How does this software know what policy is appropriate for which employee? How is that policy distributed? What is the interface that allows a policy to be defined? How do you protect the policy definition from subversion?
The same problems arise in the CAK case. And the same solution: you make the user's software do the same thing every time, and implement the policy elsewhere.
Access to the key-safe is critical, of course, but it can be made very secure -- a special-purpose piece of hardware that requires passwords from n out of m key czars before access is granted, for example. Or the contents of the key safe can be encrypted via keys escrowed through a secret sharing mechanism
The same problems and solutions apply in both the CAK case and in the "corporate key as extra crypto recipient" case. Now, having spent some time attempting to show that the two cases are almost identical in many respects, let me point out a few ways in which I think encrypting to a special corporate key is better than CAK. - With CAK, the key safe contains at least a copy of every key used by every staff member. All that needs to be kept secure. This storage problem does not arise in the non-CAK case. - With CAK, every time a user creates a new key, the user's software needs to talk to teh key safe. This needs a secure channel, which raises further authentication problems (how does the user know that he's not talking to a fake key safe). These don't arise in the non-CAK case. - Once a CAK infrastructure is in place, it is likely to be easier for a government to impose GAK. It's better not to set up the CAK infrastructure in the first place. To be fair, similar arguments apply to the "add an extra crypto recipient" case: just add two extra crypto recipients (corporate key and big-brother key). But I think that the general public is more likely to understand what the government wants and to reject the idea in this case than in the GAK case. --apb (Alan Barrett)