tcos / t=0 / apdu class 4 response length

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

tcos / t=0 / apdu class 4 response length

Andreas Jellinghaus-2
Hi,

my tcos card now works fine, but I had to change the attached code.
openct current is used directly, ccid driver, the reader is a scr335.

reader-openct.c:379:openct_reader_lock: called
card.c:740:sc_select_file: called; type=2, path=3f00
card.c:253:sc_transmit_apdu: called
card.c:220:sc_transceive: Sending 7 bytes (resp. 258 bytes):
00 A4 00 00 02 3F 00 .....?.
card.c:273:sc_transmit_apdu: Received 0 bytes (SW1=67 SW2=00)
iso7816.c:98:iso7816_check_sw: Wrong length
card-tcos.c:497:hacked_iso7816_select_file: returning with: Wrong length
card.c:762:sc_select_file: returning with: Wrong length
SELECT FILE failed: Wrong length

I'm no t=0 export, so I have no idea if this is ok or not.
but a simple grep showed me "active_protocol" is only set by pcsc
driver, but neither by openct nor by ct-api driver.

so I wonder: should mangeling the APDU be done by the reader driver?
or should we add code for the other reader drivers to publish the
protocol?

I don't know if it is possible, but a high level api like opensc
should not need to care about lower level protocols.

what can we do?

Regards, Andreas

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel

opensc-card-fix.diff (636 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: tcos / t=0 / apdu class 4 response length

Nils Larsch
Andreas Jellinghaus wrote:

> Hi,
>
> my tcos card now works fine, but I had to change the attached code.
> openct current is used directly, ccid driver, the reader is a scr335.
>
> reader-openct.c:379:openct_reader_lock: called
> card.c:740:sc_select_file: called; type=2, path=3f00
> card.c:253:sc_transmit_apdu: called
> card.c:220:sc_transceive: Sending 7 bytes (resp. 258 bytes):
> 00 A4 00 00 02 3F 00 .....?.
> card.c:273:sc_transmit_apdu: Received 0 bytes (SW1=67 SW2=00)
> iso7816.c:98:iso7816_check_sw: Wrong length
> card-tcos.c:497:hacked_iso7816_select_file: returning with: Wrong length
> card.c:762:sc_select_file: returning with: Wrong length
> SELECT FILE failed: Wrong length
>
> I'm no t=0 export, so I have no idea if this is ok or not.
> but a simple grep showed me "active_protocol" is only set by pcsc
> driver, but neither by openct nor by ct-api driver.
>
> so I wonder: should mangeling the APDU be done by the reader driver?

well, I'm no reader expert as well but as far as I understand
sc_transceive it should build the TPDU as defined in ISO 7816-4
(see for example [1]) and hence it needs to know whether T0 or
T1 is used.

> or should we add code for the other reader drivers to publish the
> protocol?

if my above assumption is correct that would be necessary

>
> I don't know if it is possible, but a high level api like opensc
> should not need to care about lower level protocols.

someone must build the TPDU, if the reader layer does it, ok than
the active_protocol changes shouldn't be necessary in card.c.
Unfortunately I can't find the mail leading to this change ...

Cheers,
Nils

[1]
http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816-4_annex-a.aspx
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: tcos / t=0 / apdu class 4 response length

Andreas Jellinghaus-2
can we simply undo that change?
if people set case4as3 masquerading, it has the
same effect (with T=1).

and in scb we already set it by default, that way
cryptoflex works, and I have not received any
complain about it.

sure, it might be nice to get the current protocol
from openct, too, but right now there is no such
function and that part is being worked on anyway,
and I would like to not depend opensc on some
unfinished openct code.

once the openct changes are done, tested and well
workin, we can add a more appropriate solution again.
ok?

Regards, Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: tcos / t=0 / apdu class 4 response length

Laurent Pinchart
In reply to this post by Nils Larsch
> > my tcos card now works fine, but I had to change the attached code.
> > openct current is used directly, ccid driver, the reader is a scr335.
> > [...]
> > I'm no t=0 export, so I have no idea if this is ok or not.
> > but a simple grep showed me "active_protocol" is only set by pcsc
> > driver, but neither by openct nor by ct-api driver.
> >
> > so I wonder: should mangeling the APDU be done by the reader driver?

> well, I'm no reader expert as well but as far as I understand
> sc_transceive it should build the TPDU as defined in ISO 7816-4
> (see for example [1]) and hence it needs to know whether T0 or
> T1 is used.

I think this should be handled by OpenCT. ISO-7816 defines T=0 and T=1 as
transport protocols between readers and ICCs. They both manglet APDUs into
TPDUs, which are protocol specific. In my opinion, the reader layer (OpenCT)
should mangle the APDUs and take care of all protocol-specific operations, to
expose an APDU-based API to higher levels. Higher level applications and
libraries should not care about the protocol at all. PC/SC defines
SCARD_PROTOCOL_OPTIMAL to "provide hint to reader that it should attempt to
negociate optimal communications settings with the card". Keeping protocol
knowledge in the reader layer would mean that applications would benefit from
more efficient protocols transparently without having to support them
explicitely.

> > or should we add code for the other reader drivers to publish the
> > protocol?
>
> if my above assumption is correct that would be necessary

If my assumption is correct, that would be unnecessary :-)

> > I don't know if it is possible, but a high level api like opensc
> > should not need to care about lower level protocols.
>
> someone must build the TPDU, if the reader layer does it, ok than
> the active_protocol changes shouldn't be necessary in card.c.
> Unfortunately I can't find the mail leading to this change ...

Building the TPDU in OpenCT makes more sense to me. How does PC/SC client
applications behave ? Do they build the TPDUs themselve or let PC/SC do the
job ? In the later case, we should do it in OpenCT. And in the first case, we
should fix that broken behaviour and do it in OpenCT as well ;-)

Laurent Pinchart
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: tcos / t=0 / apdu class 4 response length

Ludovic Rousseau
On 19/09/05, Laurent Pinchart <[hidden email]> wrote:
> Building the TPDU in OpenCT makes more sense to me. How does PC/SC client
> applications behave ? Do they build the TPDUs themselve or let PC/SC do the
> job ? In the later case, we should do it in OpenCT. And in the first case, we
> should fix that broken behaviour and do it in OpenCT as well ;-)

PC/SC API does not convert APDU into TPDU for T=0 cards. So the
application has to builds TPDU itself.

It is a bad choice in PC/SC but I don't think we can change that. In
fact it may not be possible to automatically convert APDU in TPDU
since it is not easy to know what GET RESPONSE to send (in particular
what class byte to use if I remember correctly).

Bye,

--
 Dr. Ludovic Rousseau
 For private mail use [hidden email] and not "big brother" Google
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: tcos / t=0 / apdu class 4 response length

Nils Larsch
In reply to this post by Laurent Pinchart
Laurent Pinchart wrote:
...

>>>I don't know if it is possible, but a high level api like opensc
>>>should not need to care about lower level protocols.
>>
>>someone must build the TPDU, if the reader layer does it, ok than
>>the active_protocol changes shouldn't be necessary in card.c.
>>Unfortunately I can't find the mail leading to this change ...
>
>
> Building the TPDU in OpenCT makes more sense to me. How does PC/SC client
> applications behave ? Do they build the TPDUs themselve or let PC/SC do the
> job ? In the later case, we should do it in OpenCT. And in the first case, we
> should fix that broken behaviour and do it in OpenCT as well ;-)

Well, as a libopensc developer I would of course prefer to let openct or
pcsc do this job (as it's really a low level issue), However the quesion
is does pcsc-lite support this or not (perhaps Ludovic knows more ;-).
If the pcsc-lite does not do this (or the windows pcsc version)
libopensc must implement support for this.

Cheers.
Nils
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: tcos / t=0 / apdu class 4 response length

Laurent Pinchart
In reply to this post by Ludovic Rousseau
> > Building the TPDU in OpenCT makes more sense to me. How does PC/SC client
> > applications behave ? Do they build the TPDUs themselve or let PC/SC do
> > the job ? In the later case, we should do it in OpenCT. And in the first
> > case, we should fix that broken behaviour and do it in OpenCT as well ;-)
>
> PC/SC API does not convert APDU into TPDU for T=0 cards. So the
> application has to builds TPDU itself.
>
> It is a bad choice in PC/SC but I don't think we can change that. In
> fact it may not be possible to automatically convert APDU in TPDU
> since it is not easy to know what GET RESPONSE to send (in particular
> what class byte to use if I remember correctly).

http://archives.neohapsis.com/archives/dev/muscle/2001-q3/0043.html

Seems you are right. Some very old cards require a different GET_RESPONSE. And
it's a bad design decision in PC/SC.

The APDU->TPDU conversion can be handled at 3 different levels: in the
application layer (OpenSC), in the reader driver layer (OpenCT, PC/SC) or in
the reader itself.

Are there readers currently supported by OpenCT which translate APDUs to TPDUs
directly ? If so, the best place to build TPDUs for the other readers is in
OpenCT. OpenCT already handles APDUs to TPDUs translation in proto-t0.c and
proto-t1.c.

PC/SC compatibility can be achieved by transforming TPDUs to APDUs in the
OpenCT PC/SC interface.

Laurent Pinchart
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: tcos / t=0 / apdu class 4 response length

Andreas Jellinghaus-2
In reply to this post by Ludovic Rousseau
On Monday 19 September 2005 14:19, Ludovic Rousseau wrote:
> PC/SC API does not convert APDU into TPDU for T=0 cards. So the
> application has to builds TPDU itself.
>
> It is a bad choice in PC/SC but I don't think we can change that. In
> fact it may not be possible to automatically convert APDU in TPDU
> since it is not easy to know what GET RESPONSE to send (in particular
> what class byte to use if I remember correctly).

So let me rephrase my question:
long term it might be nice to pass an sc_apdu to the reader driver,
and it can do whatever it thinks is best?

currently generic sc_*  functions do a lot that is only used
by pcsc code. so we can either implement e.g. get_protocol for
the other drivers, too, or we can move the pcsc specific
code into the pcsc reader driver - but that needs an api
change from tpdu to apdu.

Right now I guess we want to concentrate on a 0.10 release
and not do either change. setting apdu_masquerade = case4as3
is an acceptable workaround for now, I think.

Regards, Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: tcos / t=0 / apdu class 4 response length

Nils Larsch
Andreas Jellinghaus wrote:

> On Monday 19 September 2005 14:19, Ludovic Rousseau wrote:
>
>>PC/SC API does not convert APDU into TPDU for T=0 cards. So the
>>application has to builds TPDU itself.
>>
>>It is a bad choice in PC/SC but I don't think we can change that. In
>>fact it may not be possible to automatically convert APDU in TPDU
>>since it is not easy to know what GET RESPONSE to send (in particular
>>what class byte to use if I remember correctly).
>
>
> So let me rephrase my question:
> long term it might be nice to pass an sc_apdu to the reader driver,
> and it can do whatever it thinks is best?
>
> currently generic sc_*  functions do a lot that is only used
> by pcsc code. so we can either implement e.g. get_protocol for
> the other drivers, too, or we can move the pcsc specific
> code into the pcsc reader driver - but that needs an api
> change from tpdu to apdu.
>
> Right now I guess we want to concentrate on a 0.10 release
> and not do either change. setting apdu_masquerade = case4as3
> is an acceptable workaround for now, I think.

if reader-openct.c doesn't set the active protocol value we could
simply test if T0 is used and then modify the TPDU if necessary
(instead of testing if T1 is set). This shouldn't hurt drivers not
setting this value.
Btw: what was the reason for this "apdu_masquerade" option ?

Cheers,
Nils
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: tcos / t=0 / apdu class 4 response length

Chaskiel Grundman-3
--On Monday, September 19, 2005 23:07:02 +0200 Nils Larsch
<[hidden email]> wrote:

> Btw: what was the reason for this "apdu_masquerade" option ?

Some pcsc reader drivers properly chop off the Le byte in a case4 t=0 tpdu,
and some don't.
Some pcsc reader drivers properly add a 0 Lc byte to a case1 t=0 tpdu, and
some don't.

the examples I know of are the somewhat-unmaintained egate driver that I
originally wrote, and the sun pcsc shim. I think that the egate driver is
better about this now, but I don't know for sure. I'm pretty sure that
there are other examples of the first problem, since opensc already had the
functionality (in the form of apdu_fix=<boolean>) before either of the
other devices was in common use.

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: tcos / t=0 / apdu class 4 response length

Nils Larsch
Chaskiel M Grundman wrote:

> --On Monday, September 19, 2005 23:07:02 +0200 Nils Larsch
> <[hidden email]> wrote:
>
>> Btw: what was the reason for this "apdu_masquerade" option ?
>
>
> Some pcsc reader drivers properly chop off the Le byte in a case4 t=0
> tpdu, and some don't.
> Some pcsc reader drivers properly add a 0 Lc byte to a case1 t=0 tpdu,
> and some don't.

as I've learned today pcsc expects TPDUs and hence the apdu_masquerade
option seems to be somewhat useless as it looks more like a problem in
sc_transceive. A case 1 TPDU has the form
"CLA || INS || P1 || P2 || 0x00" if T0 is used => libopensc currently
has a bug in sc_transceive. The same is true for a case 4 TPDU, it must
have the form  "CLA || INS || P1 || P2 || P3 = Lc || Lc Bytes" if T0
is used.

So instead of having this "apdu_masquerade" option it might be better
to fix sc_transceive (well, it's actually not specified what
sc_trasceive should do so perhaps the current behaviour is intended ...)

Cheers,
Nils
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: tcos / t=0 / apdu class 4 response length

Andreas Jellinghaus-2
In reply to this post by Nils Larsch
On Monday 19 September 2005 23:07, Nils Larsch wrote:
> if reader-openct.c doesn't set the active protocol value we could
> simply test if T0 is used and then modify the TPDU if necessary
> (instead of testing if T1 is set). This shouldn't hurt drivers not
> setting this value.
> Btw: what was the reason for this "apdu_masquerade" option ?

no idea. but as far as I can tell setting it to "case4as3" was
needed for quite some time on windows with cryptoflex cards.
I don't know if anyone uses the other options. stef and martin
might now better.

Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: tcos / t=0 / apdu class 4 response length

Andreas Jellinghaus-2
In reply to this post by Nils Larsch
On Monday 19 September 2005 23:53, Nils Larsch wrote:
> So instead of having this "apdu_masquerade" option it might be better
> to fix sc_transceive (well, it's actually not specified what
> sc_trasceive should do so perhaps the current behaviour is intended ...)

my questions are:
1.) is there a need to do something now? i.e. before 0.10.*?
    to me it looks like apdu_masquerade=case4as3 is a valid hack.
2.) if we want to work on it: what about changeing the reader driver
    interface to pass apdu and let the reader driver convert it to
    tpdu? that way ct-api, openct and pcsc can each do what they think
    it is best. It looks to me like we currently have lots of pcsc
    specific code in the general functions, and that does not look right.

what do you think?

Regards, Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: tcos / t=0 / apdu class 4 response length

Nils Larsch
In reply to this post by Andreas Jellinghaus-2
Andreas Jellinghaus wrote:

> On Monday 19 September 2005 23:07, Nils Larsch wrote:
>
>>if reader-openct.c doesn't set the active protocol value we could
>>simply test if T0 is used and then modify the TPDU if necessary
>>(instead of testing if T1 is set). This shouldn't hurt drivers not
>>setting this value.
>>Btw: what was the reason for this "apdu_masquerade" option ?
>
>
> no idea. but as far as I can tell setting it to "case4as3" was
> needed for quite some time on windows with cryptoflex cards.
> I don't know if anyone uses the other options. stef and martin
> might now better.
what about the attached patch. As openct (and ctapi) don't set the
active_protocal value there should be no difference for them. If
pcsc[-lite] is used it should correctly build the TPDU for the T0
protocol, thus removing the need for the "case4as3" and "case1as2"
apdu_masquerade option ("case1as2_always" option might still be
necessary as this really seems to be bug in the reader[driver]).

Cheers,
Nils

Index: src/libopensc/card.c
===================================================================
--- src/libopensc/card.c (Revision 2605)
+++ src/libopensc/card.c (Arbeitskopie)
@@ -129,6 +129,8 @@
  return 0;
 }
 
+/** Builds TPDU and sends to the reader driver
+ */
 static int sc_transceive(sc_card_t *card, sc_apdu_t *apdu)
 {
  u8 sbuf[SC_MAX_APDU_BUFFER_SIZE];
@@ -161,6 +163,9 @@
  *data++ = apdu->p2;
  switch (apdu->cse) {
  case SC_APDU_CASE_1:
+ if (card->slot->active_protocol == SC_PROTO_T0)
+ /* TO adds an additional 0x00 byte to the TPDU */
+ *data++;
  break;
  case SC_APDU_CASE_2_SHORT:
  *data++ = (u8) apdu->le;
@@ -183,10 +188,9 @@
  return SC_ERROR_INVALID_ARGUMENTS;
  memcpy(data, apdu->data, data_bytes);
  data += data_bytes;
- if (apdu->le == 256)
- *data++ = 0x00;
- else
- *data++ = (u8) apdu->le;
+ if (card->slot->active_protocol != SC_PROTO_T0)
+ /* unless T0 is used add Le byte */
+ *data++ = (u8) (apdu->le & 0xff);
  break;
  }
  sendsize = data - sbuf;

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: tcos / t=0 / apdu class 4 response length

Nils Larsch
In reply to this post by Andreas Jellinghaus-2
Andreas Jellinghaus wrote:

> On Monday 19 September 2005 23:53, Nils Larsch wrote:
>
>>So instead of having this "apdu_masquerade" option it might be better
>>to fix sc_transceive (well, it's actually not specified what
>>sc_trasceive should do so perhaps the current behaviour is intended ...)
>
>
> my questions are:
> 1.) is there a need to do something now? i.e. before 0.10.*?
>     to me it looks like apdu_masquerade=case4as3 is a valid hack.

I think it would be better if opensc works without editing the
config file.

> 2.) if we want to work on it: what about changeing the reader driver
>     interface to pass apdu and let the reader driver convert it to
>     tpdu? that way ct-api, openct and pcsc can each do what they think
>     it is best. It looks to me like we currently have lots of pcsc
>     specific code in the general functions, and that does not look right.

agree, but as this a bigger change we should do it after the next
release.

Cheers,
Nils
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: tcos / t=0 / apdu class 4 response length

Priit Randla
In reply to this post by Nils Larsch
Nils Larsch wrote:

> Andreas Jellinghaus wrote:
>
>> On Monday 19 September 2005 23:07, Nils Larsch wrote:
>>
>>> if reader-openct.c doesn't set the active protocol value we could
>>> simply test if T0 is used and then modify the TPDU if necessary
>>> (instead of testing if T1 is set). This shouldn't hurt drivers not
>>> setting this value.
>>> Btw: what was the reason for this "apdu_masquerade" option ?
>>
>
> what about the attached patch. As openct (and ctapi) don't set the
> active_protocal value there should be no difference for them. If
> pcsc[-lite] is used it should correctly build the TPDU for the T0
> protocol, thus removing the need for the "case4as3" and "case1as2"
> apdu_masquerade option ("case1as2_always" option might still be
> necessary as this really seems to be bug in the reader[driver]).
>
> Cheers,
> Nils

    Ok, please be gentle with me now. I just can't follow you any more...
So it isn't apdu but tpdu coming to the reader driver _always_?
app -> opensc -> transmit tpdu -> pc/sc driver?
app -> opensc -> transmit tpdu -> ct-api driver?
app -> opensc -> transmit tpdu -> openct driver?

Priit

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: tcos / t=0 / apdu class 4 response length

Nils Larsch
Priit Randla wrote:

> Nils Larsch wrote:
>
>> Andreas Jellinghaus wrote:
>>
>>> On Monday 19 September 2005 23:07, Nils Larsch wrote:
>>>
>>>> if reader-openct.c doesn't set the active protocol value we could
>>>> simply test if T0 is used and then modify the TPDU if necessary
>>>> (instead of testing if T1 is set). This shouldn't hurt drivers not
>>>> setting this value.
>>>> Btw: what was the reason for this "apdu_masquerade" option ?
>>>
>>>
>>
>> what about the attached patch. As openct (and ctapi) don't set the
>> active_protocal value there should be no difference for them. If
>> pcsc[-lite] is used it should correctly build the TPDU for the T0
>> protocol, thus removing the need for the "case4as3" and "case1as2"
>> apdu_masquerade option ("case1as2_always" option might still be
>> necessary as this really seems to be bug in the reader[driver]).
>>
>> Cheers,
>> Nils
>
>
>    Ok, please be gentle with me now. I just can't follow you any more...
> So it isn't apdu but tpdu coming to the reader driver _always_?

PCSC needs TPDUs and as I'm no reader expert I can't make statements
about the other reader drivers. However the proposed patch should not
affect openct and ctapi (as they do not set the active_protocol field).
In the long term it might be better a solution to feed the reader driver
(i.e. reader-openct.c etc.) with sc_apdu object and let them decide
what to do with it (doing the APDU -> TPDU conversion in reader-pcsc.c
if needed), but that's something that should be done _after_ the next
release.

Cheers,
Nils
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: tcos / t=0 / apdu class 4 response length

Andreas Jellinghaus-2
In reply to this post by Nils Larsch
On Tuesday 20 September 2005 09:48, Nils Larsch wrote:
> > my questions are:
> > 1.) is there a need to do something now? i.e. before 0.10.*?
> >     to me it looks like apdu_masquerade=case4as3 is a valid hack.
>
> I think it would be better if opensc works without editing the
> config file.

but is there any small change we can do that will not break ct-api
and openct? I didn't see any suggestion for that. extending the
openct protocol to add a new command etc. is not a short term option.

Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: tcos / t=0 / apdu class 4 response length

Andreas Jellinghaus-2
In reply to this post by Nils Larsch
> what about the attached patch.

oops. should have read bth mails before answering the
first one. looks fine to me, please apply.

Regards, Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: tcos / t=0 / apdu class 4 response length

Andreas Jellinghaus-2
In reply to this post by Priit Randla
On Tuesday 20 September 2005 10:14, Priit Randla wrote:>
>     Ok, please be gentle with me now. I just can't follow you any more...
> So it isn't apdu but tpdu coming to the reader driver _always_?
> app -> opensc -> transmit tpdu -> pc/sc driver?
> app -> opensc -> transmit tpdu -> ct-api driver?
> app -> opensc -> transmit tpdu -> openct driver?

yes, the apdu to tpdu conversion takes place in
the common code, before the result is passed to
the reader driver (the interface code for pcsc,
openct and ct-api).

so we are adding a work around in that common code,
the workaround will be active for pcsc only.

the cleaner design I think we should do someday,
is to pass an apdu to the pcsc, openct or ct-api
specific code, as they know best how to transform
it into an tpdu (or keep it as apdu).

but for 0.10.0 I'd be happy to get some small fix
done right now (or none at all / users need to edit
config file), and Nils small patch looks fine to me.

Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
12