[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Distributed Capabilities
From: |
Jonathan S. Shapiro |
Subject: |
Re: Distributed Capabilities |
Date: |
Tue, 28 Mar 2006 12:10:10 -0500 |
On Tue, 2006-03-28 at 10:21 +0200, Marcus Brinkmann wrote:
> At Mon, 27 Mar 2006 14:05:09 -0500,
> "Jonathan S. Shapiro" <address@hidden> wrote:
> > > However, in practice, as Marcus said, everyone is free to run whatever
> > > OS they may like.
> >
> > Not necessarily. This is an example of one of the *valid* uses of remote
> > attestation. Attestation gives me the ability to form my associations
> > with other people selectively. The right to assemble selectively is a
> > fundamental freedom that is currently not supported in computational
> > systems.
>
> I don't buy it. For the possibility to assemble selectively, you only
> need secrecy and the ability to establish an identity. For this,
> normal public key authentication is sufficient.
This is complete nonsense. The identity you are trying to establish here
is the identity of the remote *platform*, not the identity of the remote
*user*.
I agree that the user needs to be able to say "no, do not answer that
identity challenge". However, assuming that the user is *willing* to
identify, it does not follow that the user is *able* to identify.
Even if I trust you, Marcus, personally, and even though you personally
are quite expert, you are simply not capable of giving me any *credible*
assurance of what is running on your system. The reason is that in
practice you do not actually *know* what is running on your system.
Upgrades make it impossible to track this in practice.
Further, there are valid circumstances where even if I trust *you*, I
know that certain possible system configurations are known to be
compromised, and I therefore cannot trust your system if it is one of
these configurations -- even if you say that it is okay. The issue here
is that you are trustworthy but your system is not sufficiently within
your control.
So: any robust mechanism for selective assembly must answer two
independent questions:
1. Do I trust the remote administrator/user?
2. Do I have credible reason to believe that the remote
administrator/user is, in fact, in control of their system.
> Control over
> behaviour of others is orthogonal to identification and secrecy.
The question at hand is not control. It is credibility.
> To
> push your analogy further, in a modern society only the state has the
> executional power to control others (except for emergencies,
> parentship etc).
Nonsense. This is a perfect example of thinking wrongly about authority.
In most modern societies, only the state has the *authority* to execute
people, but in practice every individual in the world has the *ability*
to execute people. In consequence, the fact that people are not executed
routinely has nothing to do with the absence of authority, and the
notion that execution can be controlled by authority is fundamentally
flawed, and authority is entirely the wrong framework for thinking about
this. The reason that individuals do not execute other individuals is
(societally speaking) the sufficient statistical likelihood of reprisal.
What the state actually has is authority to execute **with exemption
from reprisal.** Even that is debatable, since terrorists may engage in
reprisals against the individuals who collectively make up the
institution of the state.
shap
- Distributed Capabilities, (continued)
- Re: Distributed Capabilities, Eric Northup, 2006/03/27
- Re: Distributed Capabilities, Ludovic Courtès, 2006/03/27
- Re: Distributed Capabilities, Eric Northup, 2006/03/27
- Re: Distributed Capabilities, Ludovic Courtès, 2006/03/28
- Re: Distributed Capabilities, Jonathan S. Shapiro, 2006/03/27
- Re: Distributed Capabilities, Marcus Brinkmann, 2006/03/28
- Re: Distributed Capabilities,
Jonathan S. Shapiro <=
- Re: Distributed Capabilities, Marcus Brinkmann, 2006/03/28
- Re: Distributed Capabilities, Jonathan S. Shapiro, 2006/03/28
- Re: Distributed Capabilities, Marcus Brinkmann, 2006/03/28