Re: Restricted storage

[Jonathan S. Shapiro]

On Thu, 2006-06-01 at 17:35 +0200, Bas Wijnen wrote:
> 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.

1. This is a different failure mode.
2. When I said "donate", I did not mean "revocably".

> 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.

Your assumption, not mine.

> 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).

In most circumstances, the decision to trust the OS owner involves a
much smaller degree of exposure than the decision to trust the machine
owner.

> > 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)?

Easy: In one case, they *only* need to rely on the OS+TC builders. In
the other case, they need to rely on OS+TC+Installer. One dependency set
is strictly larger than the other (therefore has lower confidence). I
would add: of these, the Installer is the weakest link; there is a
qualitative reduction in confidence here.

shap