Le lundi 09 janvier 2012 à 10:34 +0100, Frank Morgner a écrit :
> Executing PACE is now also tested with Reiner SCT RFID standard and
> Reiner SCT RFID komfort. Meaning that all known readers to be able to
> perform PACE conforming to BSI TR-03119 or respectively PC/SC Pt. 10
> amendment 1 can be u
Hi!
> > 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
On Saturday, January 07 at 09:20PM, Frank Morgner wrote:
> 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 i
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 fo
Hello!
On Tue, Nov 15, 2011 at 23:25, Frank Morgner
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 (in
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
> > > tr
