Hi! > > Ah yes, I forgot about that. It's already long ago... Anyway, the idea > > of sc_transmit_bytes has been given up in favor of sc_bytes2apdu, since > > all the opensc tools do not want to send an arbitrary buffer but an > > apdu. > > Will you propose a new patch? > > >> 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"). Cheers, Frank.
pgpYiDJpXCcTw.pgp
Description: PGP signature
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
