Hi! > IIRC the original discussion had a few combined aspects: > * splitting sc_transmit into an APDU version and byte array version (yes) > * exporting the byte array version to libopensc (libopensc "removal" > from exported interfaces was to discourage relentless linking against > libopensc for "smart card support" a la linking against OpenSSL if you > only need sha1.c)
I don't agree on this point. The OpenSSL guys know what they are doing and this is the most important thing when you are programming security related software. Implementing SHA-1 yourself feeling self-confident only because you read "Applied Cryptography" is not a good idea... > * removing the "control" piggybacking from sc_transmit (and exporting > the outcome) > > Given the goal of OpenSC (to provide applications access to on-card > cryptographic keys through standard interfaces) the implementation of > tricks (like using SCardControl to start secure PIN entry) is supposed > to happen inside OpenSC. Also, the focus should be on PC/SC (unless > you have other requirements) > > > > I would prefer the one-function-each-operation-approach, meaning that I > > just add `execute_pace` to `sc_reader_operations`. What is your opinion? > > Internally, the API should facilitate re-use by OpenSC components and > card drivers. Sorry, I have not had the time to learn about PACE more > than the generic overviews, nor how it fits into the > cards-and-readers-and-current-software-stack bigger picture. Given > that what you want to do can be done above PC/SC, extending the reader > callbacks structure with only a "control" function should be enough. > The rest should either fit into a card driver (if it makes no sense as > a generic function) or implemented/triggered by a layer different from > the card driver (like current pinpad code, inside reader-pcsc.c or in > some new file in src/libopensc) As said, I added execute_pace to sc_reader_operations and implemented everything for the PC/SC reader driver. The npa-tool can be used to actually execute PACE on the reader. Next week I can test with Reiner SCT's readers. So far it works fine with the ccid-emulator. Source code is more or less derived from http://vsmartcard.sourceforge.net/ and can be found here https://github.com/frankmorgner/OpenSC > > By the way, who knows where I can find information about CT-API > > extensions (not the CT-API itself) such as the CTBCS commands from > > OpenSC? > > No idea. I'd suspect the specs are in German anyway. Fine with me, if someone comes up with such a document... ;) Cheers, Frank.
pgpvlUnlfZhDV.pgp
Description: PGP signature
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
