[E-Lang] Java 2 "Security" (was: Re: WelcomeChrisSkalkaand S
cottSmith of Johns Hopkins)
Wed, 24 Jan 2001 12:49:41 -0800
> -----Original Message-----
> From: Jonathan S. Shapiro [mailto:email@example.com]
> Sent: Tuesday, January 23, 2001 5:56 AM
> To: Ben Laurie
> Cc: Mark S. Miller; David Wagner; firstname.lastname@example.org
> Subject: Re: [E-Lang] Java 2 "Security" (was: Re:
> ScottSmith of Johns Hopkins)
> Ben Laurie wrote:
> > "Jonathan S. Shapiro" wrote:
> > > Defense in depth also becomes appropriate for "second
> chance" security.
> > > A major problem with capability systems is: "What do I do
> *after* I make
> > > a mistake?" In the real world, we often know that the
> recipient does not
> > > act immediately. It is desirable to be able to undo an erroneous
> > > transmission. This, by the way, is where ACLs come in to play.
> > Isn't this trivially solved with revocable capabilities?
> No it isn't. The problem is that I have some object A. I give
> cap(A) to
> you intentionally and correctly. I give cap(A) to Fred by
> accident. If I
> revoke A, then the copies of cap(A) that I gave to you get lost too.
> Unfortunately, the feasible recovery strategies introduce some very
> serious security issues.
> There really is a valid argument for some form of ACL here.
I disagree that ACLs are needed for selective revocation. One way is to
have a system that gives you the ability to clone a capability. Then you
can selectively revoke a single clone and leave the others alone. That's
what we had with e-speak Beta 2.2. With the current release of e-speak, you
create a delegated certificate which can be revoked modulo CRL propagation.
> e-lang mailing list
Decision Technology Department
Hewlett-Packard Laboratories MS 1U-2
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-6278