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

[Kevin Reid]

On May 12, 2009, at 18:45, Zooko O'Whielacronx wrote:

> 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.

Note, however, that you can't (afaik; I haven't actually dived into  
the architecture to really know) currently put those URLs into a Tahoe  
directory, because Tahoe directory items aren't arbitrary URLs.

http://allmydata.org/trac/tahoe/ticket/683 -- hint hint. You have just  
presented another use case.

> 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.

This is not revocation:

  1. anyone running a storage server or having previously downloaded  
shares can hold onto the ciphertext, so deleting shares has no  
guaranteed effect, and you're only removing data that they could have  
already downloaded and decrypted anyway. (There is value in this --  
"oops, I uploaded this private data, delete it before anyone downloads  
it" -- but it is not a guarantee, not even the sufficiently-good- 
guarantee of crypto-with-a-decent-number-of-key-bits.)

  2. It does not disable access to a shared resource /which continues  
to exist and be shared except for the revoked access/, which I proffer  
as a sketchy definition of revocation.

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>