Hello, Martin Paljak wrote: > > On 03.10.2009, at 15:19, Aleksey Samsonov wrote: > >> Hello, >> Martin, could you explain please what for we need this change? >> http://www.opensc-project.org/opensc/changeset/3752/branches/martin/0.12/src/libopensc/apdu.c >> >> >> if SC_APDU_CASE_3_SHORT and apdu->datalen == 0 and >> apdu->lc == 0 then no error? Why? > The reason is written here: > http://itacns.corp.it/hg/itacns/file/adc0b2ceec86/patches/100-itacns.patch#l345
Thanks, I didn't see this. --- 346 + * The Italian CNS seems to want a 0 byte at the end of the command, 347 + * (a TLV structure with implicit tag, 0 length?) 348 + * This requires patching apdu.c as well. --- I think, here should be SC_APDU_CASE_1 and then SC_PROTO_T0, but if SC_PROTO_RAW then this is the task to handle in card reader driver (OpenCT). > It made me think about it and I don't really know if it is OK or not, > can't really decode ISO either with 100% clearity. > > Relevant copies from > - > http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816-4_5_basic_organizations.aspx#chap5_3 > > > - > http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816-4_annex-a.aspx#AnnexA_3 > > > > In case 3, the length Lc is not null; therefore the Lc field is present > and the data field consists of the Lc subsequent bytes. I consider that Lc is not null definitely. > I can't really judge if it is OK from ISO point of view or not (should > not, but feels like could be). But if it makes a card work, I believe it > is OK. I am left with the impression that a Lc byte in position B1 can > be 0x00 to note that bytes B2..0 are 0 bytes of data. > > What do you think? Now it's clear, thanks. But still, I believe that the patch is not correct and this is the case of SC_APDU_CASE_1. We can make this card work only if we'll change code at "level SC_PROTO_RAW, SC_PROTO_T0". _______________________________________________ opensc-devel mailing list [email protected] http://www.opensc-project.org/mailman/listinfo/opensc-devel
