[cap-talk] Managing Domains, section 13

[John Carlson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>
> Thanks for taking time to look more closely at that algorithm.  I  
> personally
> think it's quite an elegant approach (e.g. the object description  
> data - the
> 'designation' - showing up as clear text when received by the server,
> the fact that the server need note be involved in capability  
> communication,
> the fact that clients can safely view the clear text of the object  
> designation,
> etc.).
>
yes, those are all positives.  If you can recall, I implemented a  
capability
system with GPG.  Unfortunately, I had no easy way to protect the  
server's
keys...they were only protected by ACLs.  I know that Jeff Kalibjian at
HP did a lot of work on their security stuff (I don't exactly recall  
what
he worked on even though he gave a talk on it).  He used to work at
LLNL.  Perhaps you've met him.

>> You'd have a more convincing story if you were actually using
>> public/private keys in some fashion, like in email.
>
> You lost me with the above.  I believe I am.  I suggest in that paper
> a means for communicating permission tokens (object capabilities)
> as data on a network.  I've come to believe that what most refer to
> as "confinement" (and I didn't deal with in that paper) where
> object capabilities are strongly POLA in that they also constrain
> communication to only happen through valid capabilities is also
> needed in an effective network "operating system" (process
> domain management).
>
Hmm.  I don't see any sign of PGP, GPG, SHA1 hash, signature
or any encryption of email on your part.

>
>> If you ask the user to provide a capability to a server, then you're
>> just asking for phishing again.
>
> I don't understand the above comment.  Why so?

Never mind, it doesn't apply to public/private keys.  It would apply
to someone putting a YURL into the wrong web page.



>
> I'm hoping we can enhance the object/capability paradigm to meet
> the needs of those who are looking for accountability/auditability  
> (identifying
> who did what) and identity based access management (e.g. revoke
> just the access of a bad apple) while still accepting the reality of
> allowing delegation as is inevitable between communicating entities.
> This is an effort to get the "best of both worlds".  I hope it's  
> successful.
> If so perhaps we'll have something new to fire back at the ACL  
> advocates.
> More capability myths demolished.

I'm perfectly willing to spend some more time on my directory & file  
servers
that I wrote in Java.  I need someone to handle the public/private  
key stuff--in
the kernel I assume, and I would need a design for a revocable  
capability
that can be used with public/private keys--I guess you essentially  
take the
public key off your key ring to revoke it?  That seems effective.  I  
think there
was some logging in my implementation, but it would have to be polished
up.

Once we deal with capabilities, we can tackle electronic voting.

John
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFFXt215YNwhxymDAMRAlFYAKC3aRijKe2e/lb2vIdN80JB4tMtkgCgzwwt
HeMU6K4N/ba2kiL9gQxxB2g=
=UH2n
-----END PGP SIGNATURE-----