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
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. The length Le is null; therefore the Le field is empty. Consequently, the body consists of the Lc field followed by the data field. In cases 2, 3 and 4 the body of the command APDU consists of a string of L bytes denoted by B1 to BL as illustrated by figure 5. Such a body carries 1 or 2 length fields; B1 is [part of] the first length field. Case 3S - L=1 + (B1) and (B1) != 0 • B1 codes Lc (=0) valued from 1 to 255 • B2 to Bl are the Lc bytes of the data field • No byte is used for Le valued to 0. In this case, Lc is valued from 1 to 255 and coded on byte B1 (='00'). Which leaves me clueless is the last part, "coded on byte B1 (='00')" 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? -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 _______________________________________________ opensc-devel mailing list [email protected] http://www.opensc-project.org/mailman/listinfo/opensc-devel
