[E-Lang] Ownership certificates via capabilities?

[hal@finney.org]

Mark M. writes:

> To re-establish context, this message is in reply to Hal's
> http://www.eros-os.org/pipermail/e-lang/2001-February/004533.html .
>
> At 01:32 PM Saturday 2/24/01, hal@finney.org wrote:
> >I know certificates are not particularly well thought of around here, Nevertheless both
> >of these seem to be necessary to solve the problem.
>
> I cry: *False Dichotomy!!*
>
> There are two orthogonal distinction being conflated here.  The first is 
> between capabilities and other security models.  As everyone knows, I'm a 
> shameless capability advocate.  The other is between on-line and off-line 
> media for implementing a security model.  You have indeed set up a problem 
> that an on-line system, almost by problem definition, cannot solve.  You 
> have explained the need for an off-line certificate system to solve it.  
> Fine, no problem.  The remaining question is: can an off-line capability 
> certificate system do at least as well as any alternative?  If you agree 
> this is the right question, I'm happy to argue for this conclusion.

I think this is a good question.  David Wagner raised a similar issue
in private mail: isn't cryptographic certificate, such as I used in my
off-line solution, essentially an off-line capability?

> E itself is currently on-line oriented and mostly on-line -- only on-line 
> for invocation, and mostly on-line for references.  A "cap:..." URI is an E 
> capability that can be transferred off line (in a bearer/secrecy style, 
> rather than an authorization-chain style).  Much the same can be said of 
> Hydro.  As I understand it, E-Speak2.2 is only on line, both for 
> invocations and for references.

What I replied to David is that a cryptographic cert like SPKI is more
than a capability.  It has extra attributes over and beyond what a "bare"
off-line capability would need.  Specifically, off-line certificates
can be cryptographically verified by third parties.  It seems to me
that this is not a property of "bare" capabilities.  In E, a capability
cannot be verified in this way.  If I am given a pointer in E, all I can
do is to give it messages, or to try passing it to someone and see what
they think of it.  I can't tell, just by looking at it, who issued it
or whether it has any specific properties.  Yet with crypto certificates
I can make these kinds of determinations.

It is this additional ability to have independent third-party verification
of certs which lets the off-line card game work.  So even if we can
think of these certs as capabilities, it seems to me that the properties
of these certs that allow them to work are not those that make them
capabilities, but other properties.

For example, I think Mark has said that off-line capabilities can be
done without public key encryption, using symmetric encryption like
DES instead.  Off-line capabilities implemented using this technology
would seemingly not be able to solve the card game problem, because they
can't be third-party verified.

However I must admit that my understanding of these issues is very
sketchy.  David asked me, well then, what kind of solution could you
expect to see using capabilities?  Haven't I defined the problem in such
a way that any use of capabilities would not apply?  Maybe so, but I
don't know if that means that the problem is ill posed, or whether it
is significant that capabilities cannot deal with it (assuming that is
the case).

Hal