At 10:53 PM 9/3/2002 Tuesday, Ng Pheng Siong wrote: >(Pardon the crossposting.) > >Hi, > >I'm building a web app which, rather typically of web apps, constructs >URLs on the fly. > >A URL concocted by my app looks like this: > > https://whatever/object?action=something&expiry=timeval&cap=XXYYZZ > >The "cap" at the end is supposed to be a capability. ;-)
Please read http://www.erights.org/elib/capability/ode/ode-protocol.html . The quotes below are from that page. From what you say later, it looks like the purpose of this last string is to be an unguessable randomly chosen number, though I don't understand the purpose of the other info you're mixing in. We call an unguessable randomly chosen number used for this purpose a SwissNumber "since it has the knowledge-is-authority logic loosely attributed to Swiss bank accounts". In any case, a stringified cryptographic capability needs three parts. The first is routing hint information to help find an object to talk to that allegedly corresponds to the object designated by that capability. This routing info has no security properties beyond denial-of-connectivity issues. The other two parts provide the security: "A capability is an arrow, and an arrow has two ends. There is an impostor problem in both directions. The VatID [fingerpring of public key of designated object's host] ensures that the entity that Bob is speaking to is the one that Alice meant to introduce him to. The Swiss number ensures that the entity allowed to speak to Carol is the one that Alice chose to enable to do so." If your "https://whatever/"; above is intended to provide authentication info as well as routing, then you indeed have something analogous to all three parts. At http://www.waterken.com Tyler Close pioneered this approach to using https URLs as cryptographic capabilities, which has since also been prototyped by Kevin Lacobie for Lotus Notes. The big advantage of this approach is that regular browsers can participate in the world of distributed capabilities, as the Waterken software amply demonstrates. The disadvantage is that the capability authenticity problem, ensuring that "the entity that Bob is speaking to is the one that Alice meant to introduce him to" no longer depends on just Alice Bob and Carol, but also on VeriSign or other such external CA hierarchies. This is a rather massive expansion of vulnerabilities. Worse, it concentrates vulnerabilities in a small number of massive third parties, leading to a centralization of power. >One of my major objectives in this particular development effort is to >make it easy to automate the blackbox testing of my app. I imagine >URLs such as the above make it so: I can have code that invokes the >above URL without regard to the rest of the system. I don't understand what point you're making. >I'm creating the capability thusly: > > cap = hmac-sha1(key, "/object?action=something&expiry=timeval") > >My questions: > >1. Is the construction of the "cap" string ok? Should I stir other >info in? (The expiry timeval provides the temporal information.) > >2. The key is created from /dev/random. How long should it be? In my >threat model, the key changes every few hours. Are you happy to have your capability URLs expire when the key does? Do you have some refresh scheme in mind so that a holder of an old URL can, prior to expiration, get a fresh one? What threat (that you care about) does this expiration protect you from? ---------------------------------------- Text by me above is hereby placed in the public domain Cheers, --MarkM --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
