[cap-talk] Delegating Responsibility in Digital Systems: Horton's "Who Done It?"

[Jed Donnelley]

Sandro Magi wrote:
> Jed Donnelley wrote:
>   
>> At 07:22 AM 6/7/2007, Pierre THIERRY wrote:
>>     
>>> Wasn't providing undeniable authentication a motivation of the
>>> discussion that led to the design of the Horton protocol?
>>>
>>> Curiously,
>>> Pierre
>>>     
>>>       
>> I'd also like to see an answer to the above, partly in the hope that
>> it might help to clear up the other high level issues that I'm
>> struggling with.
>>
>> What meaning does 'responsibility' have if it is deniable?
>> For example, going back to something that James Donald wrote
>> (that I've now of course read many times):
>>
>> "Let us suppose we manage to get in place an email system
>> where all email is authenticated by a public key, but
>> not signed by a public key - that is to say, the
>> recipient knows what key it came from but cannot prove
>> this to others.  We assume entities are ultimately
>> identified by their key, not by a "true name" that is
>> somehow bound to the key."
>>
>> Can somebody (other than James I guess, since he's
>> frustrated by trying) explain to me what the above means?
>> As I understand things, nothing can be "signed by a
>> public key", only by a private key.
>>   
>>     
>
> I take the above to mean: the e-mail was sent over a channel encrypted 
> by the public/private keys (so the recipient knows who it came from), 
> but the message itself is not digitally signed by those keys (so the 
> recipient cannot prove who it came from to anyone else). The encryption 
> is only involved during message transmission.
>   
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?

What I am trying to get back to is an understanding about how
what James Donald said about using a Kerberos-like "token"
> As with kerberos, if a Bob process wants identify itself
> as a Bob process to a Carol process, then it could
> request from the single signon server a symmetrically
> encrypted token saying "This is Bob's poker process",
> symmetricaly encrypted to the key that Carol's process
> shares with the single signon server, thereby
> establishing a key that Carol's poker program shares
> with Bob's poker program, and only Bob's poker program,
> and that each program knows it shares with the other.
for responsibility delegation works in the context of POLA.  I understand
how Kerberos works in ambient authority systems like Unix and Windows.
In such systems a program running with such a token ("This is Bob's
<whatever> process") runs with Bob's full authority - ambient authority.
In capability systems of course we do not want to support ambient
authority.  Is the relevant distinction here the <whatever>?  That is,
is there an intent to issue some sort of a limited liability responsibility
token?

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?

Regarding Alan's:
-------- Original Message --------
Subject: 	Re: [cap-talk] Delegating Responsibility in Digital Systems: 
Horton's "Who Done It?"
Date: 	Thu, 07 Jun 2007 15:47:40 +0000
From: 	Karp, Alan H <alan.karp at hp.com>
Reply-To: 	General discussions concerning capability systems. 
<cap-talk at mail.eros-os.org>
To: 	General discussions concerning capability systems. 
<cap-talk at mail.eros-os.org>
References: 	<464A66B3.6010205 at cs.jhu.edu> 
<DAEB3834-A9DA-4F21-A01B-BFB30007827C at mac.com> 
<465B778B.4020702 at cs.jhu.edu> 
<20070607142243.GC7546 at bateleur.arcanes.fr.eu.org> 
<7.0.1.0.0.20070607075122.0565a910 at webstart.com>


> Jed wrote:
>   
>>> > >
>>> > >Wasn't providing undeniable authentication a motivation of the
>>> > >discussion that led to the design of the Horton protocol?
>>> > >
>>> > >Curiously,
>>> > >Pierre
>>>       
>> > 
>> > I'd also like to see an answer to the above, partly in the hope that
>> > it might help to clear up the other high level issues that I'm
>> > struggling with.
>> > 
>>     
> The motivating example did not require non-repudiation.  Recall that
> example.  Carol runs a wiki and wants to know who is responsible for
> posting spam so she can remove that party's ability to post.  Carol
> doesn't have to prove to anyone else the identity of the spammer.  
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.

Continuing from Alan:

> Each request from a different responsible party comes through a
> different forwarder under Carol's control.  That provides Carol
> undeniable authentication.  However, Carol can't prove that to anyone
> else because the forwarder is under her control.  For example, she could
> have sent the request herself.
Right.  This is what Horton provides.  To get non-repudiation it would 
seem that Carol
would have to get support from the Horton system of stubs - keeping logs 
of where the
sealers and unsealers were applied.  This may be too much for practical 
application,
but for me the fact that it could in principle be done provides me 
comfort that there
is substance to the claims of responsibility - 'undeniable' responsibility.

At this point the undeniability business is a minor sidelight for me.  
I'm still focusing
my efforts on determining how Kerberos-like identity tokens 
(authenticated channels?)
can be used to assign (delegate) responsibility in a POLA system.  I'm 
at the point
of dropping out of the email 'discussion' (frustrating and perhaps 
wasting people's
time) in the hopes that I can get some interactive time at some point 
with somebody
to clarify this issue.

--Jed
http://www.webstart.com/jed/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20070607/525efbee/attachment-0001.html