On Thu, Jun 01, 2006 at 10:28:12AM -0400, Jonathan S. Shapiro wrote: > > > > > Indeed. And while we are about it: where do you propose to store > > > > > keys that are used for group signatures? > > > > > > > > In some place that cannot be destroyed by any of the members of the > > > > group, but only by the group administrators. That is, in a special > > > > user account created specially for that group. > > > > > > Ah. So you propose that the computational "right of assembly" should be > > > present only with the consent of the system administrator? > > > > Can you pelase define what you mean by "computational 'right of > > assembly'"? The term is entirely void of meaning to me. > > If the group keys should be stored in a specially created account, then > the system administrator's permission is required in order to form a > private group.
Not at all. The system can be set up in a way that allows users to do this on their own. However, I think it is not a problem if the system administrator is required when the users want to do it at system level. Of course they can always form a group, and use opaque storage for things. Only the other members of the group can't verify it. > This seems contrary to freedom. It is not much different from how you plan to do it though. Suppose I do this without system support. I join a group and donate some storage to it. A part of a private key gets stored on that storage. I decide to leave the group and revoke my storage. Then the private key that was (partly) stored on it is lost, giving the whole group problems. If you want to make this system usable, the storage must be durable. There may be approaches which work without the system administrator, but they need support from the system, that is the machine owner. > The primary role of the administrator in this scenario is a policy > decision: how much system resource to allocate -- specifically, storage. Yes. Of course if it is system-implemented, this can be donated by users in a semi-permanent way (and the system guarantees that it is opaque). > The actual setup of the account is done entirely by software. Which means what? Just about everything in an OS is entirely done by software... > Ironically, it would be very very easy to do this without an > administrator being involved if opaque storage is present and > verifiable. Each participant can "donate" some amount of storage as a > condition of joining the group. And how can the group protect against revocation? Right, it can't. So you need to trust the members that they don't revoke the storage. > However, this only works if the participants can verify that the storage > is opaque. See below. They have to know that it is opaque. This doesn't need to be done through technical verification. It can be done, indeed, if the machine owner allows it. No difference between the systems in that respect. > > > > > The objects holding such keys must be shared, and all parties need > > > > > to be able to verify the storage safety and the identity (in the > > > > > sense of "what binary is executing here") of the key management > > > > > object. > > > > > > > > Yes. They can do that socially. > > > > > > No. The entire point of the need to verify is that you *can't* do that > > > socially, because you are forming a collaboration in which the parties > > > do not have absolute trust in each other. They will have to do it socially anyway. The trust this is about is trust in the machine owner. With TC, it is trust in the OS builder (and the TC component manufacturer). > > It's a simple error of logic to attribute "more trust", in general, to > > the one system than to the other. "Trust" is a personal conviction, > > and can not be attributed to an object without a subject. > > That soliloquy is not relevant to the point that I was making. Yes, > trust always has a subject. I did not say otherwise. Yes, trust is > always conditional, in the sense that it is predicated on certain > assumptions. > > But the factor that you seem to be ignoring is the importance of > *confidence*. Why would people have more confidence in us and the TC component builders than in the person who installed the OS on the machine (which in many cases they may be themselves)? Trust and confidence is really the same thing. I don't see what your point is here. > The ability to verify that the preconditions on which a trust decision > is based is very important to forming these relationships. But you have to trust the verification method for it. So you're just exchanging trust in the machine owner for trust in the OS builder. I can understand you trust the OS builder, because that is you. But I have no reason to assume that other people will automatically trust you, too. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html
signature.asc
Description: Digital signature
_______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
