Hello,
On Jul 1, 2010, at 02:26 , Peter Stuge wrote:
> Martin Paljak wrote:
>> SmartCardWebApplet
> It is awesome that you are putting so much effort into getting smart
> cards "to the web", but I'm afraid I personally think that a Java
> approach is an enormous mistake.
There are three different objectives here:
1) create a web component that allows signing SHA hashes without any
*card*-specific software on the host machine (This works smoothly up to Windows
7 which always wants to "windows-auto-install" card-specific minidriver from
windows update for unknown cards)
2) package JavaCard related software (GlobalPlatformJava, MuscleApplet, glue
code) into a graphical one-click frontend that happens to be delivered in a
functioning way via web (you can download it too, but you can also run it right
from the web)
3) to facilitate 1) for Estonian eID card without hard-coding it for a single
card, create infrastructure not unlike OpenSC/libopensc is. That means a
framework for card drivers with PKCS#15-ish functionality.
> I can not accept that a 1x1 pixel object would be a central part of a
> security system that needs to become *less* complicated for users.
Don't have to embed it as 1x1 or 0x0 object, that's only useful for 100%
javascripted integration. To show PIN dialogs, current out-of-browser plugin
processes approach means it is best to embed the PIN entry field to the web
page rather than a separate popup so it would be suggested to include it as a
standard size (which has to be figured out).
Also, the order of implementation is 2-1-3 (see phases on the web page)
There are two ways of using the project:
1) as a Java web start application on the web for "formatting" a JavaCard
(first for using it with OpenSC and pkcs15-init, later to create a PKCS#15 card
on the web that would be usable with OpenSC PKCS#11 and other native interfaces)
2) as a component that a developer embeds on his own website for whatever
purposes he may have (signing document hashes being the one I can forecast, as
this is a common task in Estonia and elsewhere in EU that currently is usually
done with browser plugins which a. require installation b. depend on
client-side components c. are sometimes tied with a single card implementation)
The former is usable for the generic end-user OpenSC community for working with
JavaCards, the latter is heavily used in Estonia and mostly of interest to
developers and integrators.
"Flashing" JavaCards has nothing to do with PKCS#15, writing a hard-coded APDU
code for Estonian eID would be useless for the bigger community (unfortunately
Estonian eID pre-dates the PKCS#15 times, so it is not compatible), so an
ISO7816 master driver would cover a lot of needs for other card drivers.
Bringing in higher level operations and objects from PKCS#15 projects becomes a
framework that is easy to tweak for other cards as well.
> The need to re-implement every single component of OpenSC (card
> drivers, ASN.1 (wtf!?!"?!?) and pkcs15init) also make me believe that
> this is not the best approach.
Yes, card drivers need to be re-implemented, but I think it will be much easier
with Java than with C, given a good framework.
ASN.1core is well implemented in BouncyCastle, there are two (incompatible,
incomplete) PKCS#15 ASN.1 encoding/decoding efforts that can be re-user or
merged.
>> OpenSC currently is geared towards C and "native" applications,
>
> Don't believe the web application hype. Anything from the web is just
> a stateless pig with lots of makeup.
If you remove "WebApplet" from name and add "Java", would it make you happier?
The fact that it can be run straight off the web or that it can be embedded in
a scriptable way are just bonuses of the platform.
I'd have named it "SmartCardApplet" but to not confuse it with a JavaCard
applet, added Web.
There was recently some press announcement about how many million documents
have been signed in Estonia (30m?) and most of the signatures happen on the
web, via those components that currently depend on host-side card-specific
software.
Given the fact that I've some of the client side native plugin that are used
for giving signatures on the web, it is a purely practical decision to get a
solution (I'll even re-use the existing JavaScript interface (which sucks) for
compatibility) that does not depend on client side card related binaries.
>> SmartCardWebApplet on the other hand, is targeting the Java (1.6+)
>> platform. I'm sure there are mixed feelings about Java
>
> You could say. I think it's crap.
80+ of web users have it installed and enabled, even more people have it
installed but have knowingly disabled it.
>> * It has direct access to smart cards via javax.smartcardio in
>> Java 1.6+
>
> What I think you should do instead is work with me on creating the
> USB API that you would like to have in a crypto token. There are some
> Java wrappers for libusb, one of which has gotten fresh activity
> lately. (You could still continue the Java path, I just suggest
> working with a reasonable device instead.)
Sorry, existing smart cards (however stupid they might be) and the availability
of javax.smartcardio are the exact reasons for this effort.
I'm not interested in device development but will eagerly read about its
evolution if available.
> The software stack for smart cards is so 1970 that my brain actually
> hurts when I think about it. It's literally a big pile of protocols,
> each one fiddling about with bits(!).
True, that's why I've focused on higher level functionality. ("Business")
application integration.
>
> It is 2010 and re-implementing ASN.1 in Java (or any other language,
> but especially Java) does not strike me as being the right answer.
BouncyCastle has excellent ASN.1 utilities.
>> one-click, no-install web application
>
> Yeah right. Still need the full stack of driver crap. USB, PC/SC,
> T0/T1, ASN.1, PKCS#15, what did I forget? Oh, ISO7816, maybe more.
> You mean all of those drivers, for all common devices, are now
> available by default in MacWinLinux? Forget it.
javax.smartcardio works by default on most recent windows/mac/linux boxes with
a CCID reader. The task of this project is to fill in the PKCS#15(+ASN.1) and
ISO7816 bits.
To be honest, "I don't care" how javax.smartcardio works and I take it for
granted that it does work. Yes, there will be problems below javax.smartcardio
(like people who have wrong drivers etc) but I'll ignore it in the beginning.
--
Martin Paljak
@martinpaljak.net
+3725156495
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
