[e-lang] Constructing "capability" URLs
Mark S. Miller
markm at caplet.com
Wed Sep 4 17:48:40 EDT 2002
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 majordomo at wasabisystems.com
More information about the cryptography
mailing list