[cap-talk] Delegating Responsibility in Digital Systems: Horton's "Who Done It?"
Karp, Alan H
alan.karp at hp.com
Fri Jun 8 16:52:34 EDT 2007
> 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 only 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. That means you don't have to keep the cypertext.
Secondly, I don't believe that encryption is sufficient. 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.)
> What I am trying to get back to is an understanding about how
> what James Donald said about using a Kerberos-like "token"
> for responsibility delegation works 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. 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.
> If so (ignore the remainder if the above assumption is
> invalid - I'm just trying
> to keep things moving along), then it seems we have to focus some
> attention on the <whatever>. In this case it seems we're coming full
> circle back to something like the Horton/Mailkey proposals as MarkM
> did the reference programming for. That would be a case where the
> <whatever> is essentially an unsealed (signed) statement of delegation
> including the capability. No?
I believe so.
> I agree that non-repudiation is more than current systems
> provide and likely more
> that is needed for most applications. If the difference is
> 'just' a matter of logging
> cypher text in transaction logs, then this seems to be just a
> cost trade-off.
> If there is more to it than a simple cost trade-off then I'd
> like to know where the
> fundamental issue is.
It is more. The difference is between signing and encrypting.
Virus Safe Computing Initiative
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
More information about the cap-talk