On Apr 19, 2010, at 07:51 , Anders Rundgren wrote: > Although you didn't mention it, card initialization is the thing > that really makes things difficult for customers. FIPS201/PIV > does not even specify that part and we surely understand why :-) If you compare tokens to hard disks, then even though the disks come in a small number of standards (say, SATA HDD-s and SATA SSD-s) you still don't have a "universal" formatter. You have mkfs.ext2 and mkfs.ext4 and format.exe and whatever OS X is using etc. Yet you don't hear a lot of complaining (except ) from different users. Also, there are a lot more read-only cross-system drivers than there are read-write ones, and thus the most common complaint is "fat32 is a stupid filesystem to guarantee read-write support on all systems"
> I'm still quite uncertain on what to emulate in order to get a > middleware-free token. CCID yes, but above that level things > looks much more unclear. In the end, hardware needs software. If you piggy-back on some existing implementation (like some hardware vendors tap into the HID keyboard input stream) is a whole different story. > Andreas Jellinghaus wrote: >> my view on this issue is this: >> if you buy a smart card reader or usb crypto token, make sure it works >> perfectly with the original microsoft CCID driver, and the open source >> libccid driver for linux. if the device needs its own driver instead >> or has any problem with those standard drivers, it is not worth the >> hazzle and should be avoided. On Windows, almost everything goes as the drivers are provided by the vendor. But yes, in the long run, properly working standard solutions beat everything else. >> of course there is javacard, but it is expensive due to the patent >> fees, and it doesn't help much, as everyone implements different applets >> on top of it, so the result is different again. What patent fees? I don't see that decent JavaCards come with prices way above the native ones (I'm talking about recent cards) JavaCard is nice as it is the only viable option (in addition to MULTOS and the recently appeared .NET) to have open source and vendor-neutral solutions on the card side (in addition to the host side). They come in different flavors and different capabilities but you have the *option* to provide some non-proprietary interface on top of the capabilities of the card, what "native" cards don't have. -- Martin Paljak http://martin.paljak.pri.ee +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
