On Thu, 05 Aug 2010 12:04:25 +1000, "James A. Donald" <[email protected]> wrote: > On 2010-08-04 4:06 AM, tahoe-lafs wrote: >> Hm, would it be okay to allow people to set an HTTP 301 to a different >> cap >> of a different ''type'', such as a read-write cap instead of a >> read-only >> cap or a read-only cap instead of a read-write cap? >> >> Our tradition of transitive attenuation of authority suggests that we >> should forbid this, which means that a client which is ''following'' an >> HTTP 301 redirect should remember whatever the attenuation of the >> original >> cap was (i.e. if it was read-only or ''???'' if it was a verify-only >> cap) >> and refuse to use the new cap with authority outside of that. > > Obviously the person who sets up a 301 to greater authority *has* that > authority - so he should be able to share that authority with who he > chooses.
I'm not a security expert but I'm puzzled by the idea of attenuating the authority. Surely it can't be the client's job to implement this attenuation; it's easy to modify the client source code to skip any locally-performed attenuation and let the stronger cap flow through. This could be done in the server only if the server is known to be un-tampered-with. I think I'm with James. The person who set up the redirect is responsible for the consequences of it. But if we really wanted to attenuate the new cap, I think we'd have to do it at the time the redirect is created, not when it's accessed. The creator's client code (which they trust) would have to downgrade the cap so that the stronger cap is never sent to the storage nodes at all. The stronger cap isn't there, so no local source code changes by an attacker could possibly reveal it. -- Kyle Markley _______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
