On Sun, 11 May 1997, Kent Crispin wrote:
In the multiple recipient case, therefore, the master key is potentially used quite frequently, and hence much more exposed. There are many other differences: I won't try to go into detail here.
Good point. I happen to think that using the master key to decrypt documents is better practice than using the master key to obtain copies of other keys, but I can see both sides of this argument.
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.
Not if the encryption client encrypts to different company recipients depending on a policy (which one might want if one tries to limit the compromised master key problem described above.) Then the policy, contrary to what you state below, must be reflected in the client.
You are repeating your fallacy of assuming that the key safe (KS) case has one policy for all users and the multiple recipients (MR) case has different policies for different users. The truth is that the two issues (which model to use, and how many different policies to make visible to the users' software) are orthogonal. You can have KS with a different key safe for each user, and you can have MR with the same extra recipients for each user.
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.
Sigh. The situations are really quite different. In the KS case the policy never impacts the software; in the MR case I don't think you can avoid it.
Sigh. The same fallacy again. In the KS case, the software must know which key safe to use and how to secure and authenticate access to the key safe. In the MR case, the software must know which extra recipients to add, and the corresponding public keys. In both cases, the software is affected to some minimum extent. In both cases, you can choose to make the software more complex by adding more policy knowledge. In neither case are you forced to add more than the minimum amount of policy information to the software.
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.
Not at all. The corporate master key is used to decrypt documents in the MR case; in the KS case the master key is used to get to the key database.
What I meant was, you can make n-of-m hardware stuff for both cases. Surely you don't disagree with that?
- 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.
Not so. You have to exactly the same issue -- how does the user find out the master key to encrypt to?
Finding out which key to encrypt to in the MR case is analagous to finding out which key safe to talk to in the KS case. Securing and authenticating the channel to the key safe in the KS case is an extra issue that does not have a counterpart in the MR case. --apb (Alan Barrett)