(Frank, you're not subscribed to opensc-devel mailing list, which is not a good idea if you want to send mails here. I rescued the e-mail from moderation because it is probably of interest to others as well (unlike the viagra and "your wife photos attached" ones :) but you really should subscribe.)
Sorry for being slow on this, I was sick at home and mostly offline last week. On Oct 1, 2010, at 8:36 AM, Frank Morgner wrote: > On Thursday, September 30 at 12:02PM, Martin Paljak wrote: >>> The code (also needs a patched version of OpenSSL) is much more >>> extensive than other SM cards in opensc-sm.trunk, that's why I doubt >>> that there is a chance of integrating the nPA into OpenSC. >> What are the limitations in OpenSC? > > 1. There is no kind of abstraction in the current SM code. At the moment > every card driver implements its own version of secure messaging. > This leads to duplicated code. For example, what I saw at the first > glance is that every card driver implements bitpadding. In my > implementation I am trying to separate encoding of a SM message (which > is for the nPA defined by ISO 7816-4 section 6) and the actual > cryptography. I described the process here for my SM wrapper, > sm_transmit_apdu, > https://vsmartcard.svn.sourceforge.net/svnroot/vsmartcard/ccid/src/pace/sm.h > Adopting my aproach on the other hand would mean a rewrite of all other > card drivers with SM. There are not many card drivers with SM support (yet) and generally SM support is a somewhat moving target. Do you have practical suggestions for improvement? > 2. I suggested a change for handling SCardControl (ticket 235), because > there are readers with special capabilities for the nPA. But even > this simple suggestion (and simple patch) was not accepted. IMHO #236 does not make much sense, whereas #237 does. The patch in #237 makes perfect sense and will be included soon as it gets used by some piece of code in OpenSC, like one of the three tools. Until somebody finds the time to re-write those places to make use of it, it is not good to add a feature and then forget it and end up having dead code around. There's plenty of that already. Feel free to change some of those tools to make use of the new function to speed up the inclusion of your patch. > Currently > the discussion is stuck at the argument that OpenSC is for PKCS#15, > which the nPA doesn't support. The thing with standards is that you can call anything a standard, but nobody cares unless it is actually used by more than a few vendors (remember the XML thing by Microsoft?). PKCS#15 has been the best option this far (and has been around for quite some time), but nevertheless, it is not perfect and certainly not the only one. But it helps to try to "think like PKCS#15" when working with OpenSC. OpenSC aims for two targets: to provide tools for personalizing smart cards, and to provide tools and interfaces to use either those cards personalized by OpenSC or cards that get emulated to a PKCS#15-ish structure. OpenSC has settled on PKCS#15 for cards that it writes (but there's some code by Viktor that allows PKCS#15 initialization emulation-virtualization as well, don't know that so well yet), but it is not and should not be too hard to emulate a PKCS#15-like structure for read-only crypto cards on top of almost anything. If the internal PKCS#15 layer is not sufficient to represent the (crypto) objects on your card, please point out the deficiencies so that it could be improved. > So I suppose two things. First big > patches are not welcome, or at least they are unlikely to be accepted. I'm very sorry if you feel like this. I did not find the time to reply any sooner, nor could anyone else reply to your e-mail as it was in the moderation queue. If you are in doubt, I'd like to assure you that there is no discrimination nor acceptance barriers except for common sense and best practices in OpenSC. This has also been described in the OpenSC development policy [1], to keep it very transparent to anyone who wishes to improve and work with OpenSC. > Second, support for the nPA is not very important since it lacks > PKCS#15. If it has crypto capabilities, it is useful. It is hard if not impossible to objectively measure the importance of a card against others. As long as there's a developer and a maintainer and/or users for a card, the card becomes relevant. I think the best measure is the activity of users and developers for a given card. If you want to use nPA cards with/via OpenSC just let us know what needs to be improved or changed in OpenSC to make it happen. [1] http://www.opensc-project.org/opensc/wiki/DevelopmentPolicy#Sourcecodeversioning Cheers, -- @MartinPaljak.net +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
