Date: Tue, 4 Mar 1997 23:01:47 -0800
From: Li Gong <gong@games.Eng.Sun.COM>
Subject: Re: Comments and corrections on Authenticode (Atkinson, RISKS-18.85)

I certainly will not be the only person to feel the need to respond to Bob
Atkinson's article in RISKS-18.85.  I emphasize that this is a technical,
not political, response.  Basically, 2 comments and 1 challenge to Bob and
Microsoft.

> And, as implemented contractually and technically in the present
> release of Authenticode, when you sign code you _are_ most certainly
> taking explicit responsibility as the code's publisher, an action
> not to be taken lightly from a legal point of view.

Saying code signing gives you accountability is too simplistic.
First, you might not have an audit trail to use as supporting
evidence.  Second, history says that if a piece of software needs to
carry serious, legally binding liability, there would not be a
Microsoft or a software industry in general.  Thus accountability is a
potential, not a reality.

> ... Authenticode is still the only actually-deployed code signing ...

Netscape Navigator 4.0beta has code signing (originally shipped 1996),
and JavaSoft's JDK1.1 has applet signing (alpha last Nov and final
version shipped Feb 97).  (Potential bugs is a different discussion.)

Now the challenge.  Java has the potential to give you fine-grained access
control, whether the code is signed or not.  To realize this potential
today, one might have to customize the SecurityManager.  Future versions of
JDK will make such functionality easier to use.

ActiveX/Authenticode, however, does not seem to have such a potential.  So
tell me how to configure a Win95 system such that an ActiveX control (or
component or whatever) can read/write only to directory /tmp (or C:\tmp)
while it is prevented from all other file I/O?

Li Gong, Java Security Architect, JavaSoft