Hi! > > Actually PACE is executed with SCardControl. The current implementation > > for control commands in OpenSC would not allow executing PACE, because > > reader-pcsc.c:237 always encodes an APDU. This is OK if you are only > > using PIN verification/modification (which require an encoded APDU). But > > it is impossible to use for PACE, because the input data is something > > very different than an APDU. > > > > I have already filed a bug on this topic and proposed a solution > > http://www.opensc-project.org/opensc/ticket/236 > > Bug 236 "Better integration of SCardControl" has been closed with "wontfix" > tag. > The discussion continued in bug 237 "Allow the transmit of a raw buffer". > > I can't comment on the proposed patch. If I am correct Martin proposed > (in [1] comment 16) to simplify the changes but nobody proposed a > patch for this.
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. > 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? > > Are you interested in supporting PACE? This would allow changing the PIN > > of the German identity card (nPA) with certain PIN pad readers > > (CAT-S/CAT-K). I could also add support for doing PACE with readers > > that don't have a PIN pad, but for this I am first waiting for the final > > decisions regarding SM in OpenSC. > > In a previous mail you wrote "But there is no CCID compliant reader > that supports PACE (except ccid-emulator). " > Is it still the case? > What are the "certain PIN pad readers (CAT-S/CAT-K)" you are talking about > now? > > Bye, > > [1] http://www.opensc-project.org/opensc/ticket/237#comment:16 Currently two proprietary readers support PACE: http://www.reiner-sct.com/npa/komfort.html http://www.reiner-sct.com/npa/standard.html CAT-S and CAT-K denotes the reader class according to BSI TR-03119. (Actually I think that both readers talk something similar to CCID on the USB level.) More of these classes of pin pad readers for the nPA are expected... (Sorry, detailed information on this is only available in German.) Cheers, Frank.
pgpeQoYy4vppa.pgp
Description: PGP signature
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
