Re: Restricted storage

[Bas Wijnen]

On Thu, Jun 01, 2006 at 12:02:28PM -0400, Jonathan S. Shapiro 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".

Ah, so you want to change your system in order to allow irrevocable donations?
(Or were you planning to allow that already?  I thought you didn't.)  Well,
when allowing irrevocable donation, that is obviously opaque.  It is after all
no longer the donor's storage, so it's not his right to see it.  No difference
there between our systems either (except that I would be very very careful
with irrevocable donation, and would not allow it most of the time).

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

However, since the machine owner is likely someone you know, quite possibly
yourself, it may be preferrable to depend on them anyway.

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

No, in the other case they don't need trust in TC.

> One dependency set is strictly larger than the other (therefore has lower
> confidence).

Not true either.  The trust is not all-or-nothing, so two list of parties
which need some trust cannot be compared that way.

> I would add: of these, the Installer is the weakest link; there is a
> qualitative reduction in confidence here.

Not true again, in many cases the installer is the user himself, or a
trustworthy person (who is trustworthy especially because they can punch him
in the face if something goes wrong).

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