-
Enhancement
-
Resolution: Won't Fix
-
P2
-
None
-
1.1.1
-
sparc
-
solaris_2.5.1
The problem is one of design and is not a "bug" per se.
The complaint is with the way certificates are added to the
identitydb.obj using javakey. First off this solution requires
javakey, is secondly too high-tech for some users, and is lastly a
pain for those who could do it. The process is to much to demand
of an end user of a signed applet.
The request is that this process be automated, probably
in the plug-in. The plug-in, as a locally running process, could
prompt the user for permission to "install" the certificate into the
identitydb.obj file much as the same way Netscape does. Or
possibly allow applets to be verified using the netscape certificate
database?
It could be that an alternative and acceptable solution to
this problem already exists, but I could not find it. I have heard
that there are other inquiries/complaints out there. The only one
I found in a quick search is in response, by "kurt?", to the following
Duke Dollars Question:
DukeDollars Question
Newsgroup: security
Submitter: fsullivan
Question:
FYI_-_Applets_in_Plug-in_getting_full_access_to_system_resources
Date: Wed Jun 17 15:22:43 PDT 1998
Question number: 146
I have copied the pertinent portion here:
"It is difficult to take seriously your solution for
providing
an applet access to system resources. The javakey utility
is not included with Java Plug-in. Therefore, there is no way
for end users to complete the steps required to make the
applet have access to their systems. Even if it were included,
the process is unwieldy and beyond what can be asked of an
end-user.
Is JavaSoft making any effort to make it as easy for end
users to accept certificates with Java Plug-in as it is with
Communicator or IE4? At our company, we would like to use
Java Plug-in so that we will know on which VM our applets
will be run. But it does not seem to offer a solution for letting
our applets out of the sandbox."
There was bug id 4143685 that documented a similar issue and the
solution was to bundle the javakey with jre1.1.7 and the Java Plug-in
1.1.2 would bundle jre1.1.7. But the customer believes that this
does not solve the complexity for their end users.
The complaint is with the way certificates are added to the
identitydb.obj using javakey. First off this solution requires
javakey, is secondly too high-tech for some users, and is lastly a
pain for those who could do it. The process is to much to demand
of an end user of a signed applet.
The request is that this process be automated, probably
in the plug-in. The plug-in, as a locally running process, could
prompt the user for permission to "install" the certificate into the
identitydb.obj file much as the same way Netscape does. Or
possibly allow applets to be verified using the netscape certificate
database?
It could be that an alternative and acceptable solution to
this problem already exists, but I could not find it. I have heard
that there are other inquiries/complaints out there. The only one
I found in a quick search is in response, by "kurt?", to the following
Duke Dollars Question:
DukeDollars Question
Newsgroup: security
Submitter: fsullivan
Question:
FYI_-_Applets_in_Plug-in_getting_full_access_to_system_resources
Date: Wed Jun 17 15:22:43 PDT 1998
Question number: 146
I have copied the pertinent portion here:
"It is difficult to take seriously your solution for
providing
an applet access to system resources. The javakey utility
is not included with Java Plug-in. Therefore, there is no way
for end users to complete the steps required to make the
applet have access to their systems. Even if it were included,
the process is unwieldy and beyond what can be asked of an
end-user.
Is JavaSoft making any effort to make it as easy for end
users to accept certificates with Java Plug-in as it is with
Communicator or IE4? At our company, we would like to use
Java Plug-in so that we will know on which VM our applets
will be run. But it does not seem to offer a solution for letting
our applets out of the sandbox."
There was bug id 4143685 that documented a similar issue and the
solution was to bundle the javakey with jre1.1.7 and the Java Plug-in
1.1.2 would bundle jre1.1.7. But the customer believes that this
does not solve the complexity for their end users.