[cap-talk] What Horton cannot do? (Was: mailkey: transfer of accountability...)
James A. Donald
jamesd at echeque.com
Sat Jun 2 06:59:22 EDT 2007
James A. Donald:
>> Let us consider the application of this to some real
>> world cases.
>> Let us suppose we manage to get in place an email
>> system where all email is authenticated by a public
>> key, but not signed by a public key - that is to say,
>> the recipient knows what key it came from but cannot
>> prove this to others. We assume entities are
>> ultimately identified by their key, not by a "true
>> name" that is somehow bound to the key.
Jed Donnelley wrote:
> From my perspective you are focusing on a problem that
> is orthogonal to the problem that Horton is solving.
You cannot conclude that before I have finished
describing the example real world problem, and you have
not stated a real world problem that Horton solves,
leaving it unclear what in fact it is actually supposed
> Here are what I believe to be the key points:
> 1. Many (most?) of us on this list believe strongly
> that POLA is the best (only?) effective 'solution' to
> the security problems with viruses and generally with
> untrustworthy software. We have to accept that there
> can be untrustworthy software, so what we do to
> protect ourselves is POLA.
> 2. We also strongly believe that the capabilities
> paradigm is the best (only?) effective approach for
> achieving POLA. Object/capabilities (the pure and
> simple capabilities) arise naturally as tight/clean
> object parameters from object oriented programming. As
> such they provide a natural object communication
> mechanism - capabilities - that can easily support
> POLA, with a little help from some techniques such as
> power boxes and application authority initialization
I agree with all of that, but none of that seems
relevant to the question of whether Horton is a good
idea. Horton is using the tools you describe, but good
tools do not in themselves lead to good outcomes. If
you want these tools to be adopted, they need to applied
to actual, rather than academic, problems. Horton looks
to me like the solution to a sudoko puzzle, an
intepretation confirmed by your lack of interest in
pressing real world problems.
I attempted raise a real world problem to which Horton
might be relevant, and you became bored, and snipped
without reading. That attitude is not going to get
these tools adopted.
> I recently took a careful look at this criticism (e.g.
> in the above paper). I believe that the most
> important unanswered part of that criticism was that
> capability systems are unable to log who did what for
> auditing purposes and for what MarkM has referred to
> as 'reactive' access control. In "traditional"
> capability-based systems, capabilities stand alone as
> bearer rights. There is no notion of who is
> responsible for what.
> What Horton shows is that an effective mechanism to
> determine who did what can be added to
> object/capability systems - even without changing the
> underlying capability mechanism. Simply with an added
> protocol such as Horton.
Had I been responding to such a criticism, I would have
found it sufficient to say that one can track who is
using a capability, and who was issued the capability.
Horton seems to me the approach of a mathematician,
rather than an engineer. Mathematicians infamously
"solve" problems by "reducing" them to an already solved
problem, which "reduction" tends to make the problem
much bigger, rather than much smaller.
As a demonstration that capabilities can support
identities, Horton doubtless works. As a proposal for
an actually useful system, I doubt that it works.
> It does not directly address the problem that you seem
> to be focused on. The problem of spam I accept is
> important, but to me it seems quite a bit more narrow
> than the issue that we are addressing with the Horton
The problem of spam is concrete. When dealing with
abstractions, it is easy to get lost and not notice. It
seemed to me that Horton is lost and does not know it.
Building identities on top of capabilities is rather
like writing a bit wise addition operator in lisp, to
operate on bit patterns represented as sets. It can be
done, and showing it can be done tells us something
interesting about lisp, but it probably should not be
done as actual method for performing addition.
More information about the cap-talk