Raoul Duke wrote: > David-Sarah Hopwood wrote: >> Manual revocation, based on some user interface to a database that >> remembers all capabilities that have been granted (and metadata about >> the principal they were granted to, the context, etc.), would in most >> cases be far preferable. > > pardon me for stating the obvious follow on, but i will: > > and one could build the time expiry feature on top of that, if such > need really exists.
... or more generally, any arbitrary revocation policy that can be expressed in the code of a revocation agent, or several such agents. Caveat: if revocation always (or even sometimes) requires an explicit action, then it is desirable to minimize the impact of denial of service attacks against the revocation mechanism, since such attacks may be easier than more direct attacks against integrity. The way I would suggest to do this is not to automatically revoke an object on expiry of a timeout, but instead to *suspend* operations on the object on expiry of a timeout (effectively a lease), and have the revocation agent for the object periodically renew the lease before it is due to expire. Then, the object will recover from a DoS attack if and when its revocation agent recovers, and its clients will only have been delayed. (If a particular client depends on timely service, then it should implement its own timeout.) In an event-loop system, it may be sufficient to suspend objects only between turns, I think. -- David-Sarah Hopwood ⚥ _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
