Papers in PDF format

Content-Transfer-Encoding: base64
In general, applets are more complicated. Some require input parameters and some refer to non standard
classes. The Multipart/Related MIME Content-type [RELATED] could be used as a container to include the
applet, its input data as well as other referred classes. Since the applet can be considered a data object within
an HTML object, we envision a possible tight coupling between the MIME encapsulation of aggregate HTML
documents [MHTML] work and the work presented here. For example, just like an image data would be
included in a MIME encapsulation of an HTML object with a tag, an applet data could be included for
an tag. For more detailed information, please read the full version of this paper [MAPPLET].
Also please refer to our web site for the latest status of our implementation.
Using MIME Security to Sign Applets
The MIME encapsulation of an applet object is vulnerable to the same attacks as any other MIME object. In
particular, it is possible for an active eavesdropper to modify the MIME message in transit. Therefore, neither
the authenticity of the sender nor the integrity of the applet can be relied upon. The content of the MIME
message may be seen by any passive eavesdropper. To combat these security concerns, the sender of the
MIME message could sign and optionally encrypt the MIME message sent. The signature can be verified by
the recipient (assuming the public key of the sender is available) assuring the authenticity of the sender and the
integrity of the message contents. If encryption is performed, the recipient can decrypt and be assured that no
intermediary was able to read the content of the message. Encryption provides for confidentiality of the applet
during transmit.
The framework within which security services may be applied to MIME body parts is described in [RFC1847].
One can use Multipart/Signed and Multipart/Encrypted Content-Types to secure MIME objects. As an
example, consider the use of the MOSS mechanism. To sign or encrypt the applet, the applet class files are
encapsulated in Multipart/Related object which is in turn signed by MOSS and put into a Multipart/Signed
object. When the recipient gets the applet, they should verify the MOSS signature first before invoking any
application to run the applet. If the signature verification fails, the recipient mail user agent should prompt the
user a warning dialog before proceeding to the next step of invoking and/or executing the applet. Other
security considerations should follow the Java applet security guidelines. For example, the Java applet and
related classes should not be saved into a directory which is specified in the CLASSPATH environment
variable.
Comparison with Other Approaches
In [ENABLED-MAIL], the enabled or active messages are classified into four categories based on four delivery
phases: delivery-time, receipt-time, activation-time, and submission-time. The model presented in this
document can be regarded as activation-time active messaging, which is similar to Safe-Tcl approach in this
sense.
Compared to Java, Safe-Tcl lacks general purpose and interoperability with WWW. There are several
advantages of choosing Java as a platform for active messaging, mainly 1) inherent security check in Java
Applet, 2) platform independence, and 3) uniform graphic interface.
Conclusions
Embedding Java applets into a MIME object can serve both the push and pull modes well. In addition,
MIME/Java can take the advantage of several MIME based security mechanisms already in place, for example,
MOSS [MOSS]. Therefore, our approach to active messaging using MIME encapsulation is very promising.