> 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. > If parsing of certificates is the reason for using OpenSSL, then the > missing functionality of pkcs15-cert.c should be determined and > corresponding tickets should be created. Why reinventing the wheel? The code of OpenSSL is better tested and more powerful. For example, OpenSC's ASN.1 encoding doesn't allow long tags, but OpenSSL does. If OpenSC wants to support new cards there really is the need of SM support. Since this requires cryptography, some cryptographic library is needed. I have written "pace-tool" which uses OpenSC and OpenSSL to connect to the new German identity card (nPA). It also uses elliptic curve cryptography which could be of interest for you, Douglas. https://vsmartcard.svn.sourceforge.net/svnroot/vsmartcard 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. Greets, Frank.
pgpqdM7INbDKt.pgp
Description: PGP signature
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
