[cap-talk] Identity tokens (e.g. Kerberos) for responsibility labeling of capability invocations

Jed Donnelley capability at webstart.com
Sat Jun 9 04:40:31 EDT 2007

At 01:52 PM 6/8/2007, Karp, Alan H wrote:
>Jed wrote:
> >
> > Is the issue in the above whether or not the unencrypted
> > message is retained after the message is decrypted?
> > That is, if Alice is sending me a message and she:
> >
> > 1. Signs it, and
> > 2. Encrypts it with my public key  (think PGP/GPG)
> >
> > and then I receive it, decrypt it with my private and
> > unsign it with her public key, then I have the block
> > of text which I hope we agree I can 'know' (subject
> > to the strength of the encryption) is verifiably
> > associated with her identity.  Of course if I don't
> > keep the original cypher text then I have no way to
> > demonstrate that fact to others.
> >
> > Is that aspect of retained (or not) cyphertext the
> > relevant distinction here or is there more to it?
>There's more to it.  First of all, you don't unsign the message; you
>verify the signature.

This depends on the cryptographic system.  In a pure (original)
public/private key system (e.g. the original RSA as I recall)
the public key encryption is reversed by the private key "decryption"
operation (and visa versa).  The private key "decryption" can be
used as a signing operation.  I understand that in practical
production algorithms (e.g. PGP/GPG) they instead use a symmetric
encryption algorithm internally for efficiency, using the public
key operations on the symmetric encryption key.  I don't believe
this distinction is relevant to the issue of demonstrating
responsibility, as with regard to:

>That means you don't have to keep the cypertext.

I agree that in neither case (pure asymmetric cryptography or
asymmetric with an internally used symmetric encryption key)
do you "have to" keep the cypertext, but it both cases I
believe you may keep (e.g. log) the cypertext if valuable for
later use (e.g. to demonstrate responsibility).

>Secondly, I don't believe that encryption is sufficient.

I'm sorry, but you lost me with the above.  Sufficient for what?

>I guess that's
>because nobody has proved that public key encryption is collision free.
>(A quick web search and browse through the books in my office didn't
>turn up an answer.)

I don't understand how being collision free is relevant to
this discussion.

> > I'm trying to understanding how using a Kerberos-like "token"
> > for responsibility delegation can work in the context of POLA.
>Carol will only accept requests from those with accounts.  A program
>running on Bob's behalf proves that it can use Bob's account by
>authenticating to Carol.  Carol can assign responsibility to Bob because
>the program used Bob's authentication.

I understand this, but isn't it clear that at that point the program
has authenticated fully "as Bob".  That is, the program can
then claim to do anything else that it is able to do as Bob's
responsibility.  Suppose, for example, the program has also
received a capability from Dave.  With Horton the capability
from Dave may be labeled as Dave's responsibility.  In Horton (or
MarkM's reference implementation of Mailkey as I understand it) it
is the capability itself that is effectively labeled with the Dave

In the above scenario where "the program" authenticates as
Bob, then it seems to me that it can invoke the permission
granted by the capability received from Dave (or indeed any
received capability) and hold Bob responsible.  In that sense
once the authentication as Bob happens, the authority to
act as Bob is "ambient".  As you say it is the channel
(any communication from the program) that becomes Bob's
responsibility, not just permissions authorized via
capabilities labeled as Bob's responsibility.  This seems
to me (very) contrary to POLA.

Are you imagining that programs will only receive capabilities
that are the responsibility of at most one identity?  In this
case the problem is trivial (programs run as 'users') and
current ambient authority systems suffice.

>Carol grants access to objects
>on her machine based on capabilities-as-data passed in with requests.
>The program can only use those of Bob's rights that Bob explicitly
>passed to it.  Bob can enforce POLA on his program by granting it a
>subset of his capabilities.

I understand the above.  The explicit permissions may
be limited to POLA, but with this approach the program
seems to be able to make any identity that it has been
given the ability to authenticate as (having been
received as the responsible identity for some received
capability) responsible for invocations of any other
capability that it has received.  The capabilities as
data are POLA, but the identities seem to apply ambiently
to the whole program (process, active object) and can be
applied (for the purpose of establishing responsibility)
at the programs choice to any capability that it has
received as data.

I don't believe this solves the problem that you, MarkM,
I, and others were trying to solve with Horton.

Of course I can imagine such an "authorized to act as
<identity>" token being restricted to the authority
only to act as an identity (with the responsibility
of the <identity>) for an explicit and limited capability.
In that case, however, I believe we are back to something
more like Horton or Mailkey as MarkM interpreted it.


More information about the cap-talk mailing list