Re: key recovery vs data backup
On Wed, May 07, 1997 at 09:56:21PM -0700, Lucky Green wrote:
At 11:47 PM 5/7/97 -0400, Carl Ellison wrote:
I was saying that if Sam needs to read my encrypted file/mail, then I should list Sam as a crypto-recipient. If Acme,Inc. needs to read my encrypted file/mail, then I should list Acme,Inc. as a crypto-recipient.
There's no safe of keys. It's even simpler to explain to an executive.
Several people on this list asked me to elaborate on my claim that KR is not required. I doubt that I could put it more succinctly than Carl has in his post.
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. So perhaps backing up to discuss the problem a bit would be helpful. I hope you will forgive me if this is old ground. The problem is key management for an organization. The keys are used to protect and authenticate data owned, not by any individual, but by an organization. Keys are generated for the organization's purposes, not the purposes of any individual. Furthermore, the individual privacy of an individual who works for an organization is not a necessary priority for the organization. Organizations are composed of many individuals, some of which may not share the goals of the organization, or who may indeed be inimical to the organization. And the members of an organization may vary widely in competence, personal responsibility, and so on. Thus, the members of an organization cannot be trusted to do the "right thing". [I am using "organization" in a loose sense, so that we can consider a business an organization, and an employee as a member of that organization.] In fact, in most cases, only a small fraction of the members of an organization care more about the welfare of the organization than about their personal welfare. So people will almost always be more concerned about their own personal data security than they will for that of an organization. This, coupled with difficulties of coordination and control, and the above conditions, means that in a global sense information security for an organization will always be difficult, regardless of the security of the crypto they use. For a moment consider the analogy with physical keys. Consider the key management problem of a moderate sized corporation that occupies a large office building. There are office keys, storeroom keys, supply room keys, conference room keys, bathroom keys, keys to filing cabinets -- there are *lots* of keys, lots of different delegations of authority involved. In many cases there is a "key czar", a "building coordinator" that hands out keys, and gets them back when someone changes offices or jobs. It *has* to be this way -- you can't rekey the entire building when a janitor quites. So, occasionally it is necessary to rekey a lock, but typically keys are just reused. Many office keys are designed to be difficult to casually duplicate, for this reason. Of course any key *can* be duplicated, but that's not really that important -- the building is full of employees during the day, and the night watchman checks each person that enters after normal hours. All these physical keys all fit locks that can be broken quite easily -- there is essentially *no* possibility of something valuable being lost behind a lock that cannot be broken. This is vastly different from cryptographic keys -- for all systems of interest, encryption represents locks that cannot be broken. Data behind a lost cryptographic key is gone forever. You can't call a locksmith or a safe cracker. It's really just gone. 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? 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? Contrast that with a key-safe model, where a copy of every encryption key is kept in a secure database. The encryption client software only talks to the key-safe when a new key is generated, over a cryptographically secure channel, of course. There is no policy the client has to know. The user encrypts freely without concern about who else should get copies. The organization knows that there is very little chance of data loss because of lost keys, and can use any policy it chooses to recover keys, from the company president's ad hoc whim to a carefully specified organization al security policy. 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 -- Kent Crispin "No reason to get excited", kent@songbird.com the thief he kindly spoke... PGP fingerprint: B1 8B 72 ED 55 21 5E 44 61 F4 58 0F 72 10 65 55 http://songbird.com/kent/pgp_key.html
Kent Crispin <kent@songbird.com> writes:
At 11:47 PM 5/7/97 -0400, Carl Ellison wrote:
I was saying that if Sam needs to read my encrypted file/mail, then I should list Sam as a crypto-recipient. If Acme,Inc. needs to read my encrypted file/mail, then I should list Acme,Inc. as a crypto-recipient.
There's no safe of keys. It's even simpler to explain to an executive.
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.
It seems to me that it is you Kent who is scrambling to find plausible reasons why key escrow is the best or only technology to use in corporate email systems.
[long analogy to physical locks and keys on company premises]
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? 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?
Ah I see you do acknowledge what Carl Ellison and Matt Blaze have been saying on cryptography@c2, that key escrow has complexity problems, contrary to what you have previously been arguing :-)
Contrast that with a key-safe model, where a copy of every encryption key is kept in a secure database. The encryption client software only talks to the key-safe when a new key is generated, over a cryptographically secure channel, of course. There is no policy the client has to know. The user encrypts freely without concern about who else should get copies. The organization knows that there is very little chance of data loss because of lost keys, and can use any policy it chooses to recover keys, from the company president's ad hoc whim to a carefully specified organization al security policy.
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
I don't see the difference. With the encrypt to multiple recipients approach where the second crypto-recipient is the company key you can store the private half of the corporate key using the same techniques you discussed above. Access to the data requires access to the master key in both cases. You fix the second crypto-recipient in the MUA if you wish to. The fire-wall can reject posts without the second crypto-recipient. You can use binding cryptography to ensure the fire-wall can tell that it is an encrypted copy of the same document without the firewall needing access to the master key. You can't do this company has all keys in the safe model, without givin the firewall automatic access to the safe, which is a huge security risk. So, I suppose you would argue that oh no, the user can by pass this feature of the MUA, they can use a different MUA, or telnet to the SMTP port manually. Well, you know, people can bypass keys which are stored in the company safe also: don't use them! They can also walk out of the building with a floppy, store info in their heads, or use any number of subliminal channels that abound in crypto and internet protocols. The advantage of the multiple recipient model is that doesn't commit the cardinal sin/design flaw of sharing private crypto keys. Some people have argued that multiple recipient is less suited to GAK, and therefore it would be better to use multiple recipient, I'm not sure that it makes that much difference. If we get forced to put the government as the second crypto-recipient recipient, the government still gets to read all your mail. The main argument against company generates all keys, company holds all keys, to me is that it's bad crypto design. The `it's easier to explain a safe full of all employee keys' to management argument is nonsense also. It's a master key either way and just as easy to explain either way: a master key is a key that lets you decrypt all mail. Adam -- 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`
On Sat, May 10, 1997 at 07:19:40PM +0100, Adam Back wrote:
Kent Crispin <kent@songbird.com> writes:
At 11:47 PM 5/7/97 -0400, Carl Ellison wrote:
I was saying that if Sam needs to read my encrypted file/mail, then I should list Sam as a crypto-recipient. If Acme,Inc. needs to read my encrypted file/mail, then I should list Acme,Inc. as a crypto-recipient.
There's no safe of keys. It's even simpler to explain to an executive.
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.
It seems to me that it is you Kent who is scrambling to find plausible reasons why key escrow is the best or only technology to use in corporate email systems.
Not "best". "Easiest". Look at it this way, Adam -- if it was easy to implement Carl's model, it would already have happened, given the dislike of key-escrow in the cryptographic community. But, when examined in detail, in light of real requirements from organizations, it is not easy at all. I'm not "scrambling", Adam. If there is anything you need to understand here, it is that I am *not* in favor of GAK. Chisel that in stone and think about it a bit -- your misunderstanding of my motives causes you to gloss over my arguments and not think about them. I am sympathetic to your concerns, and I am trying to explain something I truly think people are missing. Think of me as intelligent, Adam, and I will do the same for you.
[long analogy to physical locks and keys on company premises]
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? 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?
Ah I see you do acknowledge what Carl Ellison and Matt Blaze have been saying on cryptography@c2, that key escrow has complexity problems, contrary to what you have previously been arguing :-)
You completely missed the point of the above paragraph -- all those questions apply to the "encrypt to policy-specified local recipients" model, and *don't* apply to the key-safe model. The key-safe model has no significant policy issues that need to be embedded in software -- the only policy is "when data encryption keys are generated a copy is sent to the key-safe (using an encrypted channel, of course)."
Contrast that with a key-safe model, where a copy of every encryption key is kept in a secure database. The encryption client software only talks to the key-safe when a new key is generated, over a cryptographically secure channel, of course. There is no policy the client has to know. The user encrypts freely without concern about who else should get copies. The organization knows that there is very little chance of data loss because of lost keys, and can use any policy it chooses to recover keys, from the company president's ad hoc whim to a carefully specified organization al security policy.
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
I don't see the difference. With the encrypt to multiple recipients approach where the second crypto-recipient is the company key you can store the private half of the corporate key using the same techniques you discussed above.
Access to the data requires access to the master key in both cases.
It follows, therefore, that if the master key is compromised in both systems, all data is compromised. From that perspective, the systems are equally secure.
You fix the second crypto-recipient in the MUA if you wish to.
This is precisely the point I was alluding to in the policy discussion above. In an organizational content, *of course* you will put all the complexity in the MUA. The question is, how do you change the "master key" indicator that is in each MUA? Suppose that the organization wants different keys for different departments -- how do you keep track of which master key goes where? How do all those MUA's get their key policy module updated?
The fire-wall can reject posts without the second crypto-recipient.
How does the key policy module in the firewall get updated?
You can use binding cryptography to ensure the fire-wall can tell that it is an encrypted copy of the same document without the firewall needing access to the master key. You can't do this company has all keys in the safe model, without givin the firewall automatic access to the safe, which is a huge security risk.
??? With the key-safe model the firewall never enters into the picture.
So, I suppose you would argue that oh no, the user can by pass this feature of the MUA, they can use a different MUA, or telnet to the SMTP port manually.
No, I wouldn't argue that -- I know perfectly well that that neither model does any good at all against a determined, competent insider. [...]
The advantage of the multiple recipient model is that doesn't commit the cardinal sin/design flaw of sharing private crypto keys.
Two things: First, any crypto system that doesn't deal with protection/recovery/secure-use of private keys is incomplete. Second, keep in mind that we are talking about encryption for an *organization's* purposes. The whole meaning of "private" is altered in that context.
Some people have argued that multiple recipient is less suited to GAK, and therefore it would be better to use multiple recipient, I'm not sure that it makes that much difference. If we get forced to put the government as the second crypto-recipient recipient, the government still gets to read all your mail.
The main argument against company generates all keys, company holds all keys, to me is that it's bad crypto design.
You say "tumato"...
The `it's easier to explain a safe full of all employee keys' to management argument is nonsense also. It's a master key either way and just as easy to explain either way: a master key is a key that lets you decrypt all mail.
At that level of generality both these systems are identical, and equally easy to explain. It's when you get down to the details that things become more interesting. -- Kent Crispin "No reason to get excited", kent@songbird.com the thief he kindly spoke... PGP fingerprint: B1 8B 72 ED 55 21 5E 44 61 F4 58 0F 72 10 65 55 http://songbird.com/kent/pgp_key.html
Kent Crispin <kent@songbird.com> writes:
On Sat, May 10, 1997 at 07:19:40PM +0100, Adam Back wrote:
It seems to me that it is you Kent who is scrambling to find plausible reasons why key escrow is the best or only technology to use in corporate email systems.
Not "best". "Easiest". Look at it this way, Adam -- if it was easy to implement Carl's model, it would already have happened, given the dislike of key-escrow in the cryptographic community.
Firstly: have you done a comprehensive survey of corporate access systems available to commerce. Secondly: there are a number of other forces "encouraging" the GAK model. Government incentives: Europe companies and research groups get given research funding to experiment with GAK/TTP architectures. Either the architecture is stipulated as part of the call for proposals, or proposals involving GAK are going to get funding more easily. Third: people involved with key recovery at all have tended to be defense contractor types, who are more likely to go with government "standards" (such as TTPs/clipper/tessera/etc).
But, when examined in detail, in light of real requirements from organizations, it is not easy at all.
I was under the impression that PGP Inc had done it, or is working on it. It's not very hard at all, all you need is PGP's existing multiple crypto-recipient feature. The storage of your company master key needs some thought, but that's a common problem with either your crypto key safe model or multiple recipient model.
I'm not "scrambling", Adam. If there is anything you need to understand here, it is that I am *not* in favor of GAK.
I have a memory. I recall you made several posts where-in you said you were against GAK. Your line of argument seems to be that the rest of us are misguided, or are allowing are dislike of GAK to cloud our judgement on what a good crypto architecture GAK would be applied to corporate key escrow. Right?
Chisel that in stone and think about it a bit -- your misunderstanding of my motives causes you to gloss over my arguments and not think about them. I am sympathetic to your concerns, and I am trying to explain something I truly think people are missing. Think of me as intelligent, Adam, and I will do the same for you.
I have no doubts as to your intelligence. I understand what you are trying to explain, and understood the first time you tried to explain; I just disagree! If you want to discuss your motives, the thing that puzzles me is that your tone, overall apparent statist tendencies, and zest on this topic are at odds with your stance on GAK. Did you ever come across a guy called David Sternlight? (Clearly an intelligent guy, but having a tendency to hang on to arguments, and stir up flame wars, in his case I'm sure this was intentional.) Not equating you to Sternlight, though there are some similarities in style. Perhaps it is just that some of us reacted negatively when you first bought this topic up, and you are still acting in retaliatorily hostile manner as a result of this. Remember it was you who called for rational calm discussion. People impute from your apparent statist leanings, and your arguments against people who are against the key-safe model because of the possibility of helping build a GAK infrastructure that you are pro-GAK. Perhaps you need to disclaim this more clearly. If I believed GAK architecture was superior to multiple-recipient, and was arguing this I don't think I'd come across in the same way. I'm not sure that multiple recipient is that much less useful to GAK than the safe model, buf if it is at all less useful, and the systems otherwise basically equivalent I would argue against the safe model for that reason alone. However I consider the safe model inferior in several areas neglecting this issue anyway.
[claimed unique and fatally complex problems with multiple recipient approach]
Ah I see you do acknowledge what Carl Ellison and Matt Blaze have been saying on cryptography@c2, that key escrow has complexity problems, contrary to what you have previously been arguing :-)
You completely missed the point of the above paragraph -- all those questions apply to the "encrypt to policy-specified local recipients" model, and *don't* apply to the key-safe model.
I contend that there are similar and mostly comparable problems with the safe model. Lets take a look at a few:
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?
Kent says give all the keys to Acme corp, or let Acme corp generate the keys. Who is Acme Corp? The next bit is as a result of multiple recipient being more flexible than the safe model as stated. We now have freedom to allow different elements in the company to audit and access different departments communications. Naturally this extra flexibility results in policy decisions.
What part of the organization that is Acme Corp is authorized to know this particular bit of information? 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?
If making policy decisions is too complex in your view for implementation or practicality, well just substitute a policy dumbed down to the level of the safe model. Ie there is one crypto recipient, all company communications _must_ be encrytped to it as a second crypto recipient. Policy distribution is something Netscape has been doing; apparently the difference between it's browsers is largely a signed policy file with a mildly obfuscated public verification key check in the code. I'm sure you can arrange this same flexibility and bring in the baggage of the policy decisions that come with it for the safe model also if you want it. Store keys for different departments in different safes. Give the master keys for the department to the department head, etc.,etc. Same problem, similar policy decisions, right?
The key-safe model has no significant policy issues that need to be embedded in software -- the only policy is "when data encryption keys are generated a copy is sent to the key-safe (using an encrypted channel, of course)."
As stated above, this is because you have chosen a single master key to go with the safe model. If you choose a single crypto-recipient, and master key encrypting the private half of that key, you largely have equivalence.
I don't see the difference. With the encrypt to multiple recipients approach where the second crypto-recipient is the company key you can store the private half of the corporate key using the same techniques you discussed above.
Access to the data requires access to the master key in both cases.
It follows, therefore, that if the master key is compromised in both systems, all data is compromised. From that perspective, the systems are equally secure.
Or similarly insecure. They are quite similar, I think multiple recipient offers more flexibility, and security advantages, as well as avoiding the sharing of private keys.
You fix the second crypto-recipient in the MUA if you wish to.
This is precisely the point I was alluding to in the policy discussion above. In an organizational content, *of course* you will put all the complexity in the MUA. The question is, how do you change the "master key" indicator that is in each MUA? Suppose that the organization wants different keys for different departments -- how do you keep track of which master key goes where? How do all those MUA's get their key policy module updated?
Sign the policy file. Certify the signing key(s). You're going to have this anway for authentication of email content.
The fire-wall can reject posts without the second crypto-recipient.
How does the key policy module in the firewall get updated?
Sign it too.
You can use binding cryptography to ensure the fire-wall can tell that it is an encrypted copy of the same document without the firewall needing access to the master key. You can't do this company has all keys in the safe model, without givin the firewall automatic access to the safe, which is a huge security risk.
??? With the key-safe model the firewall never enters into the picture.
It does for the same functionality. With the key-safe model how do you know that the ciphertexts flowing out of the building are encrypted with a key that is in your safe at all? You don't have to do the binding cryptography stuff with multiple recipients if you don't want to. With the safe model you can't do it even if you do want to.
The advantage of the multiple recipient model is that doesn't commit the cardinal sin/design flaw of sharing private crypto keys.
Two things: First, any crypto system that doesn't deal with protection/recovery/secure-use of private keys is incomplete.
For storage encryption keys where backups are not plaintext, I agree. For communication keys, you do not need to backup. Doing so weakens security. Communications keys should be transient, forward secret even. Authentication keys should be persistent, back up not required, just generate new key, and new certificates if lost. Storage keys should be backed up where necessary.
The `it's easier to explain a safe full of all employee keys' to management argument is nonsense also. It's a master key either way and just as easy to explain either way: a master key is a key that lets you decrypt all mail.
At that level of generality both these systems are identical, and equally easy to explain. It's when you get down to the details that things become more interesting.
With the safe model, to allow access to outgoing mail, you'll have to encrypt to a company key as second crypto-recipient, or to yourself, thereby allowing company access through access to your key. Quite similar to multiple recipient. Similar explanation. Adam -- 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`
On Sun, May 11, 1997 at 12:51:38AM +0100, Adam Back wrote:
Kent Crispin <kent@songbird.com> writes:
On Sat, May 10, 1997 at 07:19:40PM +0100, Adam Back wrote:
It seems to me that it is you Kent who is scrambling to find plausible reasons why key escrow is the best or only technology to use in corporate email systems.
Not "best". "Easiest". Look at it this way, Adam -- if it was easy to implement Carl's model, it would already have happened, given the dislike of key-escrow in the cryptographic community.
Firstly: have you done a comprehensive survey of corporate access systems available to commerce.
No. I personally have not. People I know have, though -- the survey was completed about -- um -- a year and a half ago, I guess. So it is somewhat out of date.
Secondly: there are a number of other forces "encouraging" the GAK model. Government incentives: Europe companies and research groups get given research funding to experiment with GAK/TTP architectures. Either the architecture is stipulated as part of the call for proposals, or proposals involving GAK are going to get funding more easily.
That's a good point.
Third: people involved with key recovery at all have tended to be defense contractor types, who are more likely to go with government "standards" (such as TTPs/clipper/tessera/etc).
I'm not so sure about this.
But, when examined in detail, in light of real requirements from organizations, it is not easy at all.
I was under the impression that PGP Inc had done it, or is working on it.
This is one reason I'm not so sure -- PGP Inc is not a defense contractor.
It's not very hard at all, all you need is PGP's existing multiple crypto-recipient feature.
If you believe all your employees will correctly use the proper PGP incantation each and every time, even when they are tired and haven't had coffee for 4 hours, and their kid is sick, and their wife is mad about something, then yes, it is simple. But of course, that is not realistic. Employees are forgetful, the organizations goals are not their goals, and the PGP UI is -- well, I find it a little awkward, at times. So PGP's multiple recipient feature is a fundamental building block, but you need something more in a crypto-client to be sure that company policy is followed. It's that "somthing more" that is the hard part. And lest we get into the macho programmer argument -- of course it's just a mere matter of design and programming.
The storage of your company master key needs some thought, but that's a common problem with either your crypto key safe model or multiple recipient model. [...] I'm not sure that multiple recipient is that much less useful to GAK than the safe model, buf if it is at all less useful, and the systems otherwise basically equivalent I would argue against the safe model for that reason alone. However I consider the safe model inferior in several areas neglecting this issue anyway. [...] I contend that there are similar and mostly comparable problems with the safe model. Lets take a look at a few:
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?
Kent says give all the keys to Acme corp, or let Acme corp generate the keys. Who is Acme Corp?
The company that bought the crypto software for the protection of company secrets. I think I said "who *in* Acme Corp", though, as a prelude to the following points, because with the multiple recipient model there is a policy decision as to which key in Acme is the master.
The next bit is as a result of multiple recipient being more flexible than the safe model as stated. We now have freedom to allow different elements in the company to audit and access different departments communications. Naturally this extra flexibility results in policy decisions.
Yes. To make use of this flexibility you now need a piece of software that allows you to produce policy decisions, sign them, and make them visible to all the crypto clients. Another mere matter of design and programming. And this bit of sortware needs to operate securely -- you can't just any joe blow subverting it.
What part of the organization that is Acme Corp is authorized to know this particular bit of information? 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?
If making policy decisions is too complex in your view for implementation or practicality, well just substitute a policy dumbed down to the level of the safe model. Ie there is one crypto recipient, all company communications _must_ be encrytped to it as a second crypto recipient.
You are right -- there is the degenerate case where the master key is fixed. However, I would contend that is *very* bad crypto design. So thus you have the problem of distributing information about a revoked master key. (Your solution, below, was that you have a signed policy statement. If you have a security breach, and are revoking a master key, how do you know what signature to trust?) Furthermore, by encrypting every document to the same master key you have actually vastly increased your exposure -- a key-safe can have a lot of special-purpose physical and cryptographic security, but the master key in the multiple recipient model is almost certainly treated the same as all other keys. For example, in the key-safe model I can just hand someone the master key on a floppy, and it doesn't do them any good, because they can't get to the key-safe -- it is physically secure. Next I walk into the physically secure facility (I, as keeper of the keys, have legitimate access), and change the master key. No security problem, no documents have been compromised, regardless of their physical location or access. With the multiple recipient model if I hand out the master key, every visible encrypted document is immediately and irrevocably compromised. So the key-safe model allows you a far greater security for your data than the multiple recipient model.
Policy distribution is something Netscape has been doing; apparently the difference between it's browsers is largely a signed policy file with a mildly obfuscated public verification key check in the code.
Completely different environment, of course -- I saw some traffic where they admitted that probably without too much effort the policy could be subverted. But I don't deny that it would be possible to build a policy distribution scheme -- but it is a non-trivial problem.
I'm sure you can arrange this same flexibility and bring in the baggage of the policy decisions that come with it for the safe model also if you want it. Store keys for different departments in different safes. Give the master keys for the department to the department head, etc.,etc. Same problem, similar policy decisions, right?
Nope. Not at all. The policy for multiple recipients needs to be interpreted by the crypto clients. But in the key-safe model policy is almost entirely in human hands. It doesn't even have to be written down. Modestly secure example: The keysafe runs on a single workstation, hardened similar to a firewall. The only network connections are to a single port, which does the cryptographically secure key storing protocol. When a key needs to be recovered, three trusted employees troop into the room (three passwords are required, these passwords are essentially the master key), and retrieve the needed key on a floppy. Other than the authentication protocol, there is *no* policy embedded in the key-safe, which is to say, *any* policy the company wants to use is ok. It may take the personal presence of the company president, it may take a signed statement from operations staff, whatever. No policy is embedded in software, and no software to support software needs to be written.
The key-safe model has no significant policy issues that need to be embedded in software -- the only policy is "when data encryption keys are generated a copy is sent to the key-safe (using an encrypted channel, of course)."
As stated above, this is because you have chosen a single master key to go with the safe model. If you choose a single crypto-recipient, and master key encrypting the private half of that key, you largely have equivalence.
Not so, as I hopefully explained above, the key-safe can have enhance security, so that the danger of a compromise is lessened.
I don't see the difference. With the encrypt to multiple recipients approach where the second crypto-recipient is the company key you can store the private half of the corporate key using the same techniques you discussed above.
Access to the data requires access to the master key in both cases.
It follows, therefore, that if the master key is compromised in both systems, all data is compromised. From that perspective, the systems are equally secure.
Or similarly insecure. They are quite similar, I think multiple recipient offers more flexibility, and security advantages, as well as avoiding the sharing of private keys.
I spoke too soon here. The key-safe model is intrinsically more secure.
You fix the second crypto-recipient in the MUA if you wish to.
This is precisely the point I was alluding to in the policy discussion above. In an organizational content, *of course* you will put all the complexity in the MUA. The question is, how do you change the "master key" indicator that is in each MUA? Suppose that the organization wants different keys for different departments -- how do you keep track of which master key goes where? How do all those MUA's get their key policy module updated?
Sign the policy file. Certify the signing key(s). You're going to have this anway for authentication of email content.
You may not be able to trust the signature. [...]
You can use binding cryptography to ensure the fire-wall can tell that it is an encrypted copy of the same document without the firewall needing access to the master key. You can't do this company has all keys in the safe model, without givin the firewall automatic access to the safe, which is a huge security risk.
??? With the key-safe model the firewall never enters into the picture.
It does for the same functionality. With the key-safe model how do you know that the ciphertexts flowing out of the building are encrypted with a key that is in your safe at all?
Oh -- I'm sorry. I didn't think through what you were saying. You were attempting to guard against an insider threat. A waste of time, probably. He could frisbee a floppy out the window to his honey in the red sports car.
You don't have to do the binding cryptography stuff with multiple recipients if you don't want to. With the safe model you can't do it even if you do want to.
How does the firewall know what is encrypted? Just a bunch of gifs of the family? Just the first 5000 lines of "Paradise Lost", slightly altered? Anyway, if the employee uses the "approved" MUA, and it isn't compromised, then it can store a copy of all outgoing mail, encrypted with the employee's key. If he doesn't use the approved MUA, or the MUA is compromised, then of course the firewall protections are useless. So, in the keysafe model, the firewall never enters the picture -- it is all handled in the MUA, anyway.
The advantage of the multiple recipient model is that doesn't commit the cardinal sin/design flaw of sharing private crypto keys.
Two things: First, any crypto system that doesn't deal with protection/recovery/secure-use of private keys is incomplete.
For storage encryption keys where backups are not plaintext, I agree. For communication keys, you do not need to backup. Doing so weakens security. Communications keys should be transient, forward secret even. Authentication keys should be persistent, back up not required, just generate new key, and new certificates if lost. Storage keys should be backed up where necessary.
I agree with all this. Only storage keys need to be in the keysafe. [...] -- Kent Crispin "No reason to get excited", kent@songbird.com the thief he kindly spoke... PGP fingerprint: B1 8B 72 ED 55 21 5E 44 61 F4 58 0F 72 10 65 55 http://songbird.com/kent/pgp_key.html
On Sat, 10 May 1997, Kent Crispin wrote:
So PGP's multiple recipient feature is a fundamental building block, but you need something more in a crypto-client to be sure that company policy is followed. It's that "somthing more" that is the hard part.
And lest we get into the macho programmer argument -- of course it's just a mere matter of design and programming.
Yes. And probably a lot less design and programming than the key-safe mechanism. (For example, PGP already has an "encrypt-to-self" option that makes it add the user's own key as an additional crypto recipient of all messages; changing that to the more general "encrypt to this list of extra keys" should be quite easy. But designing and building a key safe sounds like a lot of work to me.) Of coure, you trust the users not to use versions of PGP that do not make the corporate key a recipient of all communications, right? If not, then you also don't trust them not to use keys that have not been sent to the key safe in the CAK model.
If making policy decisions is too complex in your view for implementation or practicality, well just substitute a policy dumbed down to the level of the safe model. Ie there is one crypto recipient, all company communications _must_ be encrytped to it as a second crypto recipient.
You are right -- there is the degenerate case where the master key is fixed. However, I would contend that is *very* bad crypto design. So thus you have the problem of distributing information about a revoked master key. (Your solution, below, was that you have a signed policy statement. If you have a security breach, and are revoking a master key, how do you know what signature to trust?)
In the key-safe model, you have the problem o distributing information about a change in location (network address) of the key safe, or a change in the keys used to authenticate access to the key safe -- similar complexity in both models.
Furthermore, by encrypting every document to the same master key you have actually vastly increased your exposure -- a key-safe can have a lot of special-purpose physical and cryptographic security, but the master key in the multiple recipient model is almost certainly treated the same as all other keys.
You can use special hardware to generate the key pair and to store the private key -- again, similar issues and similar solutions in both models.
I'm sure you can arrange this same flexibility and bring in the baggage of the policy decisions that come with it for the safe model also if you want it. Store keys for different departments in different safes. Give the master keys for the department to the department head, etc.,etc. Same problem, similar policy decisions, right?
Nope. Not at all. The policy for multiple recipients needs to be interpreted by the crypto clients. But in the key-safe model policy is almost entirely in human hands. It doesn't even have to be written down.
In either model, you can have the users' software do the same thing every time (talk to teh same key safe, or encrypt to the same additional key every time); and in either model you can have the users' software do different things depending on policies (talk to different key safes, encrypt to different additional recipients). It's unfair to say "but I choose to do the same thing every time, and you choose to do different things every time, therefore my model is simpler than yours". In fact, both models are almost equally capable of being used in either the simple way or teh complex way.
Modestly secure example: The keysafe runs on a single workstation, hardened similar to a firewall. The only network connections are to a single port, which does the cryptographically secure key storing protocol. When a key needs to be recovered, three trusted employees troop into the room (three passwords are required, these passwords are essentially the master key), and retrieve the needed key on a floppy. Other than the authentication protocol, there is *no* policy embedded in the key-safe, which is to say, *any* policy the company wants to use is ok. It may take the personal presence of the company president, it may take a signed statement from operations staff, whatever. No policy is embedded in software, and no software to support software needs to be written.
Again, the same scenario plays equally well in the extra-crypto-recipient model.
I spoke too soon here. The key-safe model is intrinsically more secure.
I don't see how. --apb (Alan Barrett)
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)
I addressed many of your issues in another post, so I will be relatively brief... On Sun, May 11, 1997 at 10:24:46AM +0200, Alan Barrett wrote: [...]
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.
True.
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.
Not true. The activities are quite different in detail. In the multiple recipients (MR) case the coalition keymeisters get together to decrypt a single document; in the key safe (KS) case the keymeisters get together to decrypt a key, which can then be used to decrypt many documents. 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. The frequent use of the master key is a major problem, because in the MR case, when a master key is compromised every document in the company is exposed; whereas in the KS case, given appropriate security around the keysafe, it is not anywhere as much of a problem.
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.
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.
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.
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. Two totally different functions, two totally different security paradigms. The old saw -- you can either hide your eggs all over the case, and hope not too many of them get found, or you can put them all in one basket and guard the basket.
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.
But a relatively straightforward storage problem, really.
- 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?
- 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.
Arguable. Guv won't say "everybody has encrypt every file to the government key". Instead they will insist that the corporate master key be escrowed. Any master key is an easy target. And they will have very good excuses for it -- corporations are public entities, tax records, etc, so I don't think the public will get worked up about it. Corporations won't, either. Note that the keysafe model doesn't really need a master key -- it will work with just good physical security. In that case the Gov would just issue a subpoena, I guess. -- Kent Crispin "No reason to get excited", kent@songbird.com the thief he kindly spoke... PGP fingerprint: B1 8B 72 ED 55 21 5E 44 61 F4 58 0F 72 10 65 55 http://songbird.com/kent/pgp_key.html
On Mon, May 12, 1997 at 11:28:19AM +0200, Alan Barrett wrote:
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.
Your secretary of many years changes her passphrase, then forgets it. She has literally thousands of documents encrypted under that key. You tell her "There was a memo I put out two years ago -- we formulated a quote for them, and *I need that number*." So you call in the company security officer to decrypt all those documents, which are filed in several different places? Contrast this with just restoring the key. [...]
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.
The models I have assumed are: KS -- a single keysafe and multiple clients; MR -- a single master key generating point, and multiple clients. In the KS model all the clients talk to a single server, and there is no policy issue. In the MR case, if there is a single master key there is no policy issue that impacts the clients, but if there are multiple master keys then different clients are configured differently, according to the policy, and that configuration is controlled centrally. I confess that I hadn't considered the case of multiple keysafes in the same organization -- and for very large organizations you might want to do that. But the whole point of a keysafe is that you concentrate expense protecting the keysafe, and, in practice, it seems to me, the boundaries between keysafe domains (to coin a term) would be pretty well defined. And, the only policy issue for KS clients is which keysafe to talk to. This is pretty much fixed at installation time.
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.
You *could* design a system with multiple distributed keysafes, perhaps in an effort to minimize exposure, but I think this would be the worst of both worlds.
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?
I don't disagree that you *could* do it. I think it unlikely that you would do it for the multiple recipient case. I believe that in the MR case the master key(s) (especially if there are multiple master keys) would use exactly the same encryption algorithm as the normal encryption case. That is the obvious, straightforward way to do it. If you use another encryption algorithm for the master then you have a whole raft of other problems to deal with. And it would be crazy to require the presence of N people to decrypt any file with the master key -- consider the case of your secretary...
- 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.
?? How do you know that the channel through which you get the master key in the MR case is secure? You surely don't just pull it off the net. It's signed? Then the problem just recurses -- how do you know the signature is good? This is exactly the problem you have contacting the keysafe. -- Kent Crispin "No reason to get excited", kent@songbird.com the thief he kindly spoke... PGP fingerprint: B1 8B 72 ED 55 21 5E 44 61 F4 58 0F 72 10 65 55 http://songbird.com/kent/pgp_key.html
On Mon, 12 May 1997, Kent Crispin wrote:
What I meant was, you can make n-of-m hardware stuff for both cases. Surely you don't disagree with that?
I don't disagree that you *could* do it. I think it unlikely that you would do it for the multiple recipient case. I believe that in the MR case the master key(s) (especially if there are multiple master keys) would use exactly the same encryption algorithm as the normal encryption case. That is the obvious, straightforward way to do it. If you use another encryption algorithm for the master then you have a whole raft of other problems to deal with.
You can have the same algorithm (visible at the user side) whether or not you have special hardware for protecting the private half of the key pair from exposure.
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.
?? How do you know that the channel through which you get the master key in the MR case is secure? You surely don't just pull it off the net. It's signed? Then the problem just recurses -- how do you know the signature is good? This is exactly the problem you have contacting the keysafe.
Knowing the right key in the MR case is static information, analagous to knowing the network address of the key safe in the KS case. For example, in the MR case, the key could be distributed on a floppy disk along with the special software, while in the KS case the location of the key safe could be so distributed. OK, you also need a way of changing the (MR) key or of moving the (KS) key safe, but that doesn't happen often and similar issues would appear to arise in either case. But in the KS case, there would also need to be a mechanism to protect the channel between the user and the key safe every time the channel is used, and that extra mechanism does not appear to have a counterpart in the MR case. Not really a big deal, but it is a whole extra protocol to be designed. --apb (Alan Barrett)
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)
participants (3)
-
Adam Back -
Alan Barrett -
Kent Crispin