[E-Lang] Ownership certificates via capabilities?

[Mark S. Miller]

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:
>These two guys were into trading card games, like Magic The Gathering.

It's funny you should use this example.  At Communities.com, once us 
security types convinced everyone of the inability to copy-protect 
self-revealing media (media whose bits can only provide value at the price 
of revealing these bits), including images, the organization was left with a 
dilemma. In this graphically-oriented social decentralized virtual reality 
system, the world-objects are primarily their visual appearance, so if this 
can't be made scarce, what can?  What we came up with is transferable Title 
according to an Issuer, and the legitimacy of a Magic The Gathering card was 
our primary example for explaining this distinction.


>[...] The question was, could this be done in an offline way, [...] but afterwards I was trying to
>decide if it could be done using a different technology, certificates. [...] So I think what
>you would have to do is to have the game owner operate a database of
>who owns what cards.  This could be a distributed database represented
>by the certificates. [...] When you bought a new card from the manufacturer they would issue you
>a new certificate.  When you sell a card to someone else, the game
>manufacturer would revoke your certificate and issue a new cert for the
>new owner.  It might do this by adding the revoked certificate to its
>Certificate Revocation List (CRL).
>
>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.

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.

ACL systems are also usually only on-line.  Because ACLs are the dominant 
model, certificate systems are usually conceived of as a way to create an 
off-line ACL system (in an authorization-chain style, rather than a 
bearer/secrecy style).  SPKI is the interesting outlier here.  With the 
infamous delegation bit fixed at do-not-delegate, and with everyone 
pretending this enforces something, SPKI is a decentralized off-line ACL 
system in all ways but the Lampson criteria -- the subjects carry the 
authorization info.

With the delegation bit ignored or fixed at delegate-ok, SPKI has many of 
the attributes of a decentralized off-line capability system (although it 
falls short in many other ways).  E-Speak3 considers itself a capability 
system, and it's based fully on only SPKI.  (Note that I don't consider it 
to be a capability system, because SPKI separates designation from 
authority, and it separates authorization from invocation.)

The capability-nature of delegatable SPKI is why we devoted space to it in 
the Ode.  It's why I also started a long thread (beginning with 
http://www.eros-os.org/pipermail/e-lang/2000-October/003884.html ) working 
towards the CepCert proposal I haven't yet found the time to pull together. 
Despite its incompleteness, this thread should give a fair idea of what it 
would mean to start with SPKI, remove everything not justified by pure 
capability theory, and put in authority reduction code (the "active" part 
inspired by Nikita's work) to make up for the specialized authority 
reduction language removed from SPKI.

If you're willing to pursue this, it just might be the stimulus I need to 
get me to wrap up the CapCert proposal, in both a bearer/secrecy style and 
an authorization-chain style.  Both styles have their uses.


> and
>CRLs are even less well respected among cryptographers. 
>
>Timeliness is always an issue with CRLs.  You might have to have a rule
>that game cards can be transfered between players only during certain
>hours, [...]

If you're willing to admit the timeliness issue, and to have the players 
follow rules that render certificates inadmissible when they're outside time 
bounds, even when they haven't been seen to be listed on a CRL, then I think 
you should like the SPKI solution better on all counts:  Authorizations have 
an expiration time.  Either a new authorization is issued before the old one 
expires, or the expiration of the old one constitutes a revocation.  I think 
this is about the best revocation an off-line system can do.



        Cheers,
        --MarkM