I was able to load and execute a signed applet using OCF1.1 with the following
configurations:
* Sun Plug-in 1.1.1: the applet worked either with a PC/SC driver or with a pure
Java OCF driver (using javax.comm). One of the restrictions with this model is
that the user needs first to import the certificate of the entity that signed the
applet. Also the user has to install the Java Plug-in before being able to run
the applet.
* Microsoft VM (build 3165 or later): the applet signed with Microsoft signing
tools worked either with a PC/SC driver or with a pure Java OCF driver. Plus,
once the applet is signed, the certificate is attached to the CAB file. The user
only needs to press an "OK" button to authorize the applet to run. I think this
is a much nicer configuration than the one provided with the Java Plug-in.
* Netscape VM (build 4.05): the applet signed with Netscape signing tools did not
work for any configuration. I think the problem was that Netscape VM did not
support the reflection (???) and OCF 1.1 heavily uses the reflection package. I
did not spend too much time to investigate on this problem, so the bug could also
be related to javax.comm.
In conclusion, I recommend to use Microsoft latest VM and security model. And it
does work with javax.comm (in my demo applet, I used the OCF pure driver from
Gemplus for GCR410).
For additional info on this topic, I will write a white paper for the coming
Gemplus Developer Conference in Paris next month. This paper will be available
for download by the end of June from www.smartcardcentral.com.
Xavier Lorphelin
JSource
[EMAIL PROTECTED] wrote:
> The soon-to-be-released OCF 1.1.1 will bring better support for applets
> with various security models.
> We have tested this release using Sun's plugin under Netscape and Microsoft
> Explorer using JDK 1.1.x
> JVM.
> In addition it works under Netscape 4.07 and up JVM and Microsfot Explorer
> (newest JVM) without
> the Plugin WHEN using native CardTerminals (e.g. PCSC driver terminals).
>
> Javax.comm uses System.loadLibrary in static initializers. Static
> initializers run
> in another thread than the one you call the browser's capability API.
> That is the reason why current javax.comm cannot be used under browser's
> security policy.
>
> We have filed a bug report to SUN on this with the request to remove the
> loadLibrary call
> from static initializers.
>
> Maybe you can speed up the fixing process at SUN if you refer to this bug
> number
> and tell them that you need it:
>
> (Review ID: 54232) javax.comm under Netscape 4.07 JVM on Windows NT
>
> Peter Bendel, Smartcard Solutions, Tel.: +49-7031-16-4650, Fax -4888
> Dept. 4969, Bldg. 7103-01, Room 01-109 Lotus Notes: bed@ibmde
> IBM Pervasive Computing Division Internet: [EMAIL PROTECTED]
>
> Please visit the OpenCard Framework's homepage at http://www.opencard.org
>
> Visit the OpenCard Framework's WWW site at http://www.opencard.org/ for
> access to documentation, code, presentations, and OCF announcements.
> -----------------------------------------------------------------------------
> To unsubscribe from the OCF Mailing list, send a mail to
> "[EMAIL PROTECTED]" with the word "unsubscribe" in the BODY of the
> message.
--
___________________________________________________________________
Xavier Lorphelin
JSource, Inc. - "Your source for Java Card expertise"
465 Fairchild Drive, Suite 203 - Moutain View, CA 94043
Tel: (650)962-9600 ext 302
Fax: (650)962-1377
http://www.jsource.com
Visit the OpenCard Framework's WWW site at http://www.opencard.org/ for
access to documentation, code, presentations, and OCF announcements.
-----------------------------------------------------------------------------
To unsubscribe from the OCF Mailing list, send a mail to
"[EMAIL PROTECTED]" with the word "unsubscribe" in the BODY of the
message.
