Re: Comment on the paper by Rotondi, et al.

David Barbour <[email protected]>
Newsgroups gmane.comp.capabilities.general
Message-ID <CAAOQMStkJUH8KbJ-6VQek3+riCCFdNOah5m8pM8LTeCbMezrjg@mail.gmail.com>
Could you link to this paper?


On Fri, Jan 31, 2014 at 12:50 AM, Karp, Alan H <[email protected]> wrote:

>  I’m reading the paper section by section as time permits, and I just
> finished the piece on revocation.  Here I want to comment on the feature
> that allows revocation of just the capability and not those delegated from
> it.  I believe that feature has a serious flaw, but Marc Stiegler has come
> up with the correct variant.
>
>
>
> As described in the paper, a revocation request can be for the capability
> itself or the capability and all capabilities delegated from it.  The
> problem with the former is that it is too easy to bypass the revocation.
> Say that Alice delegates a capability that expires in a year to Bob, a
> manager in her department.  Bob re-delegates capabilities with subsets of
> the permissions to people reporting to him.  Three months later, Bob leaves
> the company under suspicion of stealing company secrets.  Alice clearly
> wants to revoke Bob’s capability, but she doesn’t want to disrupt the work
> of people in his former department.  As a result, she revokes Bob’s
> capability but not the capabilities delegated from it.  Unfortunately, one
> of those delegated capabilities was one Bob delegated to himself with a key
> not controlled by the company.  The result is that Bob retains access even
> after being fired.
>
>
>
> Marc Stiegler’s solution to Alice’s dilemma uses the distinction between
> vetted and unvetted identities.  Say that the enterprise provides a
> mechanism by which Bob denotes the target of the delegation by specifying
> someone in the company directory.  That’s a vetted identity.  If Bob
> delegates to someone not known to the enterprise, that’s an unvetted
> identity.  When Bob’s capability is revoked, the rule is to revoke all
> capabilities delegated to unvetted identities but leave the others.
>
>
>
> ________________________
>
> Alan Karp
>
> Principal Scientist
>
> Enterprise Services, Office of the CTO
>
> Hewlett-Packard Company
>
> 1501 Page Mill Road
>
> Palo Alto, CA 94304
>
> (650) 857-3967, fax (650) 857-7029
>
> http://www.hpl.hp.com/personal/Alan_Karp
>
> _______________________________________________
> cap-talk mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/cap-talk
>
>

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.