[cap-talk] Encrypted delegation via membrane [was: In Defense of Identities - not]

[coderman]

On 12/6/06, Jed at Webstart <donnelley1 at webstart.com> wrote:
>...
> >The main issue I see is the inability of Alice to delegate to Bob a
> >responsibility-tracked capability right to use Carol without involving
> >Carol.  I think that's unavoidable.
>
> This seems mostly an implementation issue.  The problem seems a bit
> like the one I solved with the public key mechanism for safely
> communicating capabilities as data in Managing Domains:
>
> http://www.webstart.com/jed/papers/Managing-Domains/#s13
>
> I'll be interested to see if there is a comparable implementation
> approach that uses cryptography and needn't involve the server
> when a permission is delegated, even with responsibility tracking.

the public key capability communication mechanism would indeed do the
trick, and does not require the server (or Carol) to be in the loop,
although you can elect for such a constraint if desired.

for example:
- Admin delegates a permissive capability (perhaps read, write, create
and delete capability on a public web sub directory) to Carol.

- Carol obtains the complex permissive capability which contains
component capabilities (represented via public keys per Jed's
description) such as: issueRWCD(), issueRWC(), issueRW(), issueR(),
audit(), and revoke() for distinct delegate-able capabilities tied to
the parent web storage capability Carol is responsible for.

- Carol does the following to grant Alice ReadOnly capability for the
web storage resource: issueR() capability via complex capability she
is responsible for and send to Alice via the pubkey encrypted method
previously referenced.  if you know you will be delegating X number of
capabilities to peers, this issue process could be performed
opportunistically by the Admin when he/she delegates the parent
complex RWCD storage capabilities.

- Carol can utilize the audit() capability to ascertain how the
delegated read capability she issued is being used, possibly revoking
the capability if Alice or someone she delegated to is abusing the
resource or is no longer authorized to read.  Note that this could
function like a pet name system, where the capability identifiers are
opaque (digest or nonce tied to pubkey?) and referenced via pet name,
"Alice", chosen during issue of restricted capabilities.  these pet
names would be used for friendly auditing, rather than any IBACs.

- Carol can utilize the revoke() capability on specific capabilities
delegated to her peers (identified by ID or pet name).  all other
capabilities (even of same type, like read) are not affected.

i'm going to assume the specifics of how such agreements and exchanges
are performed is also an implementation detail, although the overhead
mentioned earlier in this thread associated with each domain boundary
and it's associated public key based capability communication channel
is indeed a concern.

i would be curious to see if hardware acceleration (4096 bit
montgomery multiplier on padlock core?) and aggressive
caching/anticipatory key generation could make such a revocable
delegation scheme practical.


best regards,