[tahoe-dev] [cap-talk] time-based authority

[Zooko O'Whielacronx]

Here's my opinion.  About whether it is useful to have capabilities
that can be revoked, I'm sure that it is useful and I think it would
potentially offer a very large improvement in Tahoe's value for some
use cases.  About whether it is useful to have capabilities that
expire after a time-out, I am undecided.  I have a strong prejudice
against time-based control flow in general -- protocol-level timeouts
and the like usually cause more harm than good in my opinion, but
perhaps access control is an exception.  I would have to see some
empirical evidence one way or another before having a strong opinion
on that.

Now, there is an easy way to layer some such revocation on top of
Tahoe -- just run a web proxy (e.g. Apache) and give people URLs,
possibly unguessable urls or tiny urls, pointing to that web proxy.
Then you can remove items from your url database to revoke access to
them.  Allmydata.com runs a tiny url service front-end on their
production grid, but as far as I know they've never revoked any tiny
urls.

You can of course also write a program to remove items after a
time-out, thus implementing the expiry idea.

Of course, this approach means there is a central point of failure --
its destruction or unavailability can't easily be circumvented.  Also,
of course, the users of those urls are relying on that proxy to decide
what they see when they use the urls -- they don't have the ability to
check cryptographic integrity or digital signature on the resulting
file the way they do with straight Tahoe.  But, it means that you have
a traditional web site with traditional centralized control over the
content, backed by Tahoe.  Could be very interesting for some use
cases!

Another way to implement something similar to this is to use Tahoe's
garbage collection feature to delete the (ciphertext) share data even
while the person holding the cap retains the decryption key.  This
could be seen as a kind of expiry.

Now it is also possible to integrate revocation and/or expiration
deeper into Tahoe's crypto structure, so that you could have both the
distributed (reliable, available) property and the integrity property
and some form of revocation.  That would be an interesting project,
and I do think that it might add a great deal of value to Tahoe for
some use cases.  However, I'm not prioritizing it myself right now
because I have a ton of other things (Tahoe and non-Tahoe) to focus
on.  If you are a crypto hacker or want to become one and you love
that idea, by all means inquire for further instructions.  :-)

Regards,

Zooko