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 _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
