[E-Lang] Ownership certificates via capabilities?
Mark S. Miller
Wed, 28 Feb 2001 14:44:45 -0800
To re-establish context, this message is in reply to Hal's
At 01:32 PM Saturday 2/24/01, email@example.com 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
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.
>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
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.