From: "E. ALLEN SMITH" <EALLENSMITH@ocelot.Rutgers.EDU>
Date: Sat, 25 May 1996 16:39:40 +0800
To: frantz@netcom.com
Subject: Re: Runtime info flow in Java
Message-ID: <01I53OEA1Q5O8Y4ZAY@mbcl.rutgers.edu>
MIME-Version: 1.0
Content-Type: text/plain


From:	IN%"frantz@netcom.com" 24-MAY-1996 21:22:44.97

>A lot of the answer depends on what you mean by secure.  For example, if
>the Java run-time can successfully contain Java applets so they can't
>access any of the unsecured portions of your OS, then it doesn't matter
>that those OS holes exist as far as protection from the applets is
>concerned.  The proof that the Java run-time actually can do this
>containment is left as an exercise for the student :-).

	This does, of course, depend on one's knowing where the holes in the
OS are. The Java approach, at least by default, appears to be to shut all
the places where they think a hole might be, while leaving open those which an
applet practically has to use. (E.g., it shouldn't be possible under the
current design for an untrusted applet to access the disk; since an applet does
need to use the CPU, it can consume CPU time.)

>We can use certificates (ref: SPKI) to implement network capabilities. 
>These certificates make statements of the form: The holder of the secret
>key which corresponds to this public key is permitted these specific forms
>of access to this specific resource on this location (e.g. a URL).  These
>certificates can act like capabilities.  They can be passed by creating a
>new certificate for the receiver which gives it the privileges implied by
>the old certificate.  They can be rescinded in any of a number of ways.

	I suppose that the new certificate is created through a message
signed by the old certificate's private key?
	-Allen