[cap-talk] What Horton cannot do? (Was: mailkey: transfer of accountability...)

[James A. Donald]

Jed Donnelley
 > > > Uh - but the problem is solved.  Before it wasn't.
 > > > That seems to me a huge contribution.

James A. Donald:
 >> Solved in the sense that is important to
 >> mathematicians. I don't think that Horton is a
 >> solution that should be very interesting to
 >> engineers.

Jed Donnelley
 > Do you mean in the sense that there isn't a
 > significant market for object/capability system where
 > Horton could be deployed?

I think that deploying capabilities through Horton would
burden them unduly, and adversely impact the performance
and comprehensibility of the system, with adverse
consequences for the user interface.

I do not think that a capability system that employed
Horton style delegation of capabilities would be a good
idea except in special and peculiar situations with
threat scenarios unlikely to be common in practice.

 > However, if you are suggesting that the solution is
 > for some other reason impractical (with two reference
 > codings), then I would like to hear what your concerns
 > are.

No you would not like to hear, for I have been
expressing my concerns, and you do not appear to have
heard.

Jed Donnelley
 >> Repeating from my June 2nd post:
 >> : :     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...
 >> : :
 >> : :     [...]
 >> : :
 >> : :     In this situation, what does Horton buy us
 >> : :     that Rob Meijer's proposal, plus
 >> : :     authentication does not buy us?

  Jed Donnelley
 > I don't think Horton contributes anything to that
 > situation.

Yet it is the problem that Horton is supposed solve.  In
the scenario, each person issues other people
capabilities to bypass his spam filter.

If you say Horton does not contribute anything to that
situation, it seems doubtful that it contributes
anything to most such situations.

James A. Donald:
 >> So here is the same solution in general terms.
 >>
 >> Assume a system such as Zooko's triangle, where all
 >> entities have public private key pairs, a but many
 >> key pairs are unknown, and we do not in general know
 >> if the possessor of a certain key pair should be
 >> exercising a capability.   Adversaries have such key
 >> pairs as much as allies, but allied key pairs are
 >> known, while adversarial key pairs are likely to be
 >> unknown.
 >>
 >> All capabilities are shared secrets, that are issued
 >> to particular identifiable individuals.
 >>
 >> A Zooko identity is a smart browser bookmark as in
 >> the petname tool, or a smart buddy link, as in OTR
 >> IM.  A capability is an unguessable URL.
 >>
 >> In Horton, each capability is issued to one, and only
 >> one, entity, and should be exercised only by that
 >> entity.

Jed Donnelley
 > I'm not sure, but I don't think we have the same view
 > here.  What do you mean by an "entity"?

Something or someone that controls the corresponding
private key.  An entity is identified by its public key
(or hash of its public key), and url or urls by which it
may be contacted.

 > With Horton the view is that permissions as
 > capabilities can be communicated between "entities".
 > This ability to dynamically communicate permissions as
 > object/capabilities is of course the very essence of
 > the capability paradigm.
 >
 > Horton adds a mechanism that allows for a different
 > type of communication of a permission as a translated
 > capability that provides additional responsibility
 > tracking.  That is - as you see in the paper - it
 > provides for the communication of the object access c
 > from "entity" A (acting on behalf of identity Alice)
 > to entity B (acting on behalf of Bob) with a
 > translation that makes the new capability that B
 > receives distinct and labeled as having been delegated
 > with responsibility tracking from Alice to Bob.

Which is what I said "each capability is issued to one,
and only one, entity, and should be exercised only by
that entity."

 >> Alternatively, we can pass around capabilities, but
 >> since we know who is exercising them this is not too
 >> bad.   Any entity exercising a capability that we do
 >> not want widely shared, exercises after first logging
 >> on using his Zooko key. If a capability issued to
 >> Alice turns up in the hands of unknown bad people
 >> doing bad things, then Alice has been bad in sharing
 >> her capabilities unwisely, and that is Alice's fault.
 >> If a capability issued to Alice turns up in the hands
 >> of Bob, a known person who Alice could reasonably
 >> have shared it with, but Bob does bad things, then
 >> that is Bob's fault.

 > It sounds in the above as if Alice and Bob are people
 > and not running programs.

In this context, the distinction is unimportant


 > If so then I think there is an important distinction
 > between levels being missed in here somewhere, perhaps
 > by me though of course I don't see it.  The importance
 > of Horton lies in the fact that the communicating
 > entities are active objects (A, B, and C) while the
 > responsible parties are "identities" (as provided by
 > the sealer/unsealer pairs, but that we use the
 > suggestively anthropomorphic names of Alice, Bob, and
 > Carol for).

I don't see these levels as significant in this context,
and "significance" is only meaningful in the context of
real world scenarios, with realistic adversaries.
Suggest some realistic scenarios, some of today's
problems that need solving today, as I have done.  Posit
a real world scenario where it makes a significant
difference whether we pass capabilities by the Horton
mechanism or by secret sharing.

 >> If each key is unique, as is typically the case with
 >> electronic keys used in office security systems, then
 >> the owner of a key will be disinclined to share it,


 > Disinclined perhaps, but the owner must necessarily
 > share the private key (unsealer) with any software
 > acting with the authority of the owner's identity.

If your unsealer is trojaned, Horton does not help -
indeed nothing helps.

 >> whereupon knowing what key opened the lock is in fact
 >> sufficient information.

 > You lost me with the above.  Sufficient for what?
 > Sufficient to attribute responsibility to an identity?
 > How?

Think about it.  Seems perfectly clear to me.  As
always, start with the concrete example I gave.

 >> Of course, there is lots of stuff that can only be
 >> done, or is simplest to do, by passing out keys, by
 >> delegating capabilities.
 >
 > Hmmm.  From my viewpoint those two clauses above:
 >
 > 1.  PASSING OUT KEYS (even at that you don't specify
 > whether they are public keys, private keys, or some
 > other sort of key such as a metaphoric key in the
 > sense used in the KeyKOS documentation) and
 >
 > 2.  DELEGATING CAPABILITIES.
 >
 > are very distinct operations.  If you feel that they
 > are identical (that is that delegating capabilities is
 > accomplished by "passing out keys"), then I'm afraid
 > I'm lost.

For concreteness, and without loss of generality, assume
a capability is a secret unguessable url.  An
unguessable secret that enables one to do something is
ordinarily called a "key" - thus a capability is a
particular kind of key.  Several different such keys -
one issued to Alice, one issued to Bob, may well do the
same sort of thing, thus are similar capabilities.  Thus
with Horton Alice causes a capability similar to her own
to be issued to Bob, she is sharing a capability in one
sense, but in another sense, causing a new capability to
be issued.  In this second sense, the word "key" is more
meaningful.

James A. Donald:
 >> The problem is not well defined except by reference
 >> to a real or hypothetical identity system, and real
 >> resources that need protecting.  The real problem is
 >> too amorphous for us to casually assume that
 >> abstractions of it have clear meaning.

Jed Donnelley
 > The meaning of a sealer/unsealer pair, just as with a
 > public/private key pair is perfectly well defined.

The connection of that definition to anything that we
should care about, any purpose that is worth
implementing, any actual usefulness, is not so well
defined.

James A. Donald:
 >> OTR plus Rob Meijer's mailkey works by requiring two
 >> keys to access the capability, one of which the owner
 >> is likely to be disinclined to share, and one of
 >> which the owner will be inclined to share - so when
 >> the door is opened, we know "who" opened it - the key
 >> that is unlikely to be shared - and who allowed him
 >> to open it - the key that is likely to be shared.  If
 >> Alice should have allowed Bob to enter the office,
 >> the office manager presumably knows Bob, and will
 >> grill him if something bad happens.  If Alice is
 >> allowing strangers into the office, the office
 >> manager will grill Alice.

Jed Donnelley
 > Perhaps Mark or Dean can make sense of the above
 > paragraph.  I'm sorry, but I can't.

You do not seem to be in the habit of relating
generalities to specifics, or abstractions to concretes.
Try it.  The above paragraph uses synecdoche, the
particular to stand for the general, and vice versa.  If
you fail to routinely do that sort of thing, your
abstractions are likely to lose connection to reality.

  James A. Donald:
 > > Everyone on this list agrees with POLA and
 > > capabilities. Horton is an attempt to address
 > > identity through capabilities.  I don't think it is
 > > a good fit for most real world cases.

Jed Donnelley
 > Which 'real world' deployments of capabilities that
 > are applying POLA are you referring to?  Coyotos? The
 > Waterken Web Calculus?

Real world cases are problems that people actually face,
and that they need solutions for:  The stuff that
engineers and businesses get paid for.

For situations that actually arise in practice, I do not
see that Horton adds significant value as compared to
the more straightforward solution I proposed - and you
have not proposed any situation where it does add value.