Hello, On Sep 29, 2010, at 8:18 PM, Frank Morgner wrote: >> in my opinion the usage of OpenSSL in libopensc.so should be removed >> altogether. If cryptography is needed by some cards (i.e. for >> initialisation/personalisation), then this should be done by dedicated >> tools. CardOS is a good example. It requires encrypted APDU:s for the >> delete_MF and create_MF commands. This is done by cardos-tool, which has >> to be executed only before personalisation. Looking at the code of >> entersafe, gpk and oberthur I came to the conclusion, that a similar >> approach could work for these drivers too. > > I disagree. It is the whole point of card drivers to implement card > specific operations. SM and whatever needs encryption is such an > operation. Using dedicated card specific tools contradicts OpenSC's > currently used approach of using card drivers. Correct. The abundance of card-specific tools should be controlled. Also, as the line between "libopensc" and "OpenSC, with tools" is blurred, I don't see the need to draw a line between those two. Scattered use of OpenSSL and duplicated code is a different issue than requiring OpenSSL or not.
> 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? -- @MartinPaljak.net +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
