[cap-talk] Managing Domains, section 13
Jed at Webstart
donnelley1 at webstart.com
Fri Nov 17 20:44:57 CST 2006
At 05:41 PM 11/17/2006, John Carlson wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
> > I can imagine one if both sides
> > have public/private key pairs along the lines of the scheme in:
> > http://www.webstart.com/jed/papers/Managing-Domains/#s13
> > Perhaps I should get a reaction to the above discussion before
> > proceeding further.
>Jed, one problem I see with public/private key pairs is that you need
>to protect them somehow, either in the kernel, with ACLs, passwords,
>or with capabilities (or some other unknown technology) Does your
>paper discuss protecting keys, or is it assumed that capabilities are
>protecting the keys? If you have to decrypt your key everytime you
>want to use it for a capability, that could get kind of expensive.
In that paper (written in 1980 remember ;-) I say:
"The private encryption key and the intermediate results can be
protected in several ways. For example, in a multiprogrammed OS
component the transformations can be performed by the OS kernel in
response to a virtual user instruction (only the kernel knows the
process's private decryption key). In a smaller single-domain system
(e.g., a microprocessor system), it might prove effective to have the
transformations performed in a hardware device that alone knows the
system's private decryption key."
Your concern about the private keys residing in the memory space of
a process is of course well taken. Letting the private keys reside
in the memory space of the process would defeat the purpose or
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,
>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
>Another issue would be, how many public/private keys are necessary
>in a system. If only the kernel and the user need a key pair, that's
>If every single process has a key pair, you'll be spending a lot of
>time generating keys.
Every process would need a public/private key pair. I don't believe
the generation of such pairs constitute a significant overhead
compared to the cost of creating and destroying processes.
The processing time needed can be consumed beforehand
and key pairs stored so there are no significant latency issues
in process creation.
>If you have persistent processes, this helps.
>If you want each web request to live in its own space, and have its
>own set of capabilities, that's a lot of key generation--it's not
Web requests come from a Web browser, a process. One pair per
browser, not one pair per request (unless requests are forked off as
separate processes - where I'm not sure value would be added).
>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?
>I assume the things you're encrypting are very small (like bulk
>encryption keys), otherwise, the public/private key thing could get
>computationally expensive. If I have to do the public/private key
>thing for every object reference.
By "bulk encryption keys" I assume you are referring to keys for
some symmetric key algorithm? You're certainly right that
the cost of the cryptographic transformations is a concern.
That's exactly why we didn't implement this cryptographic mechanism
for safely communicating and storing capabilities as data in
NLTSS lo those many years ago. Now, however, I believe that with
more modern cryptographic techniques (e.g. caching of
symmetric keys) and modern higher speed processors, these
issues no longer constitute a serious block. I believe the more
important issues concern what 'we' want to do, can sell,
is needed, will do the job, etc., etc. e.g. as I'm trying to
pursue in the "Capabilities - the rub, an account" thread entry:
>What is your definition of a domain?
The authority of a running program - a process or active object.
>It looks like a web server
>could have several domains. How do you wall off portions of
>a web server from each other?
I had no intent to add anything to the granularity of access
control for "active object"s/processes. Domain separation
can be done at the process level as in a traditional OS
(e.g. Unix, Windows) or at a finer grained "active object"
level as those supporting object capability language facilities
>What kind of language support do you need for this?
None unless you seek finer grained protection at the thread/active
object level. Of course doing such finer grained protection would
place more demands on the performance of the cryptographic
algorithms if the section #13 approach is used. At that level
perhaps more of a descriptor level approach would be more
appropriate - translating to a capabilities as data approach at
the network level (along the lines of the DCCS:
>For conventional email PKE, also be aware that you need to
>encrypt/sign/encrypt or sign/encrypt/sign. At least that was
>from one source that I read about. I have forgotten the details,
>but it sounds like a good idea. You don't particularly have
>to do the key operation, just put the from and to in your email,
>like "Jed" and "John."
In some ways this "identity" issue is what I'm getting at in my
latest message on the "Capabilities - the rub, an account" thread:
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.
More information about the cap-talk