Re: Restricted storage

[Bas Wijnen]

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