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. 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. Currently the discussion is stuck at the argument that OpenSC is for PKCS#15, which the nPA doesn't support. So I suppose two things. First big patches are not welcome, or at least they are unlikely to be accepted. Second, support for the nPA is not very important since it lacks PKCS#15. Greets, Frank.
pgpxo5JOmzQdD.pgp
Description: PGP signature
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
