Hi! > > >> Do you need to use SCardTransmit() or SCardControl() at the PC/SC level? > > >> OpenSC mixes SCardTransmit() and SCardControl(). Maybe a good > > >> evolution would be to have separate functions. > > > > > > PACE needs SCardControl with 0x20. Yes, I think separating control and > > > transmit would be a good idea. In OpenSC this is currently mixed, > > > because every buffer sent (control or not) involves APDU parsing. That's > > > why I advocated for not parsing the buffer. But you're right that > > > separating the functionality entirely is a cleaner approach. Is there > > > something similar to SCardControl in OpenCT? > > > > I don't think we should care much about OpenCT support of an > > SCardControl() equivalent. OpenCT use is strongly deprecated. I do not > > expect to see a PACE reader supporting OpenCT but not PC/SC. A void or > > empty control() function for OpenCT would be fine with me. The idea is > > to have the code to compile with OpenCT but in a degraded mode. > > > > Thanks > > If PACE is wanted (and support for nPA), I will create a patch. > > BTW, what is the status of SM in trunk. It used to be scheduled for > 0.12.3. If there is clearity about how to integrate it, I could also > provide a generic implementation of PACE (generic = "PACE done by OpenSC > not by the reader").
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. 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 would prefer the one-function-each-operation-approach, meaning that I just add `execute_pace` to `sc_reader_operations`. What is your opinion? 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? Cheers, Frank.
pgp88ir1L8zuN.pgp
Description: PGP signature
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
