Hello! On Tue, Nov 15, 2011 at 23:25, Frank Morgner <morg...@informatik.hu-berlin.de> wrote: > I was about to add PACE on the PC/SC level, but there are some puzzeling > changes in OpenSC from the last time when I read the source code. Back > then all control commands were accessed by sc_transmit_apdu with > apdu->control = 1 (including PIN verification). Now there is a method > for perform_verify in sc_reader_operations, but still the `control`-flag > present in `transmit` (and currently only used with the CTBCS commands). > Both are contrary approaches: Either multiple functions for different > purposes or create one function that does everything with the right > input. Usually the first approach is preferred to make the code > maintainable.
The introduction of the "control" flag to sc_transmit is a purely legacy implementation, with the first attempts to add pinpad code to OpenSC. It was for CT-API and thus the poor mapping to SCardControl. > We discussed that separating transmit and control in > `sc_reader_operations` should be done cleanly. But now I am unsure if > providing one function per special operation in `sc_reader_operations` > is more what you want. If this is the case, then there should be one > created for the CTBCS commands (and in my case for pace). I don't think that CT-API/CTBCS is used that much, nor that it is very relevant or the OpenSC implementation optimal. All the vendor specs that mention CT-API I've seen recently (and I don't know of any applications using CT-API except maybe some German e-health/e-banking things) implement CT-API on top of PC/SC anyway. So *hopefully* the same functionality should be available directly through PC/SC, if there are enough open standards and specifications for a topic (things like writing to LCD displays of pinpad readers etc) Ludovic, I hope you have some interesting news from the PC/SC workgroup meeting ? :) 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) * 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) > 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. Best, Martin _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
