On Sun, 2010-08-15 at 17:11 +0300, Martin Paljak wrote: > On Aug 15, 2010, at 4:21 PM, Emanuele Pucciarelli wrote: > > On Sun, Aug 15, 2010 at 13:45, Martin Paljak <mar...@paljak.pri.ee> wrote: > >> iso7816.c should not be taken as a final, static code, if there are checks > >> missing from there, it is OK to improve iso7816.c as well :) > > > > I think that the checks already in place are all right. I guess that > > implementation quirks may arise if and when 2048-bit keys are > > supported, but currently I know of no CNS card with keys longer than > > 1024 bit, so it's safe for the time being. > > That's a good example: iso7816.c should be eventually updated to work with > extended APDU-s and 2048b keys as well.
It works very well, right now. I have a modified cardos driver, which uses both functions (signing and decipherment from iso7816.c) with keys of 2048 bit. Seems to me, that there is nothing to be done here. @martin: When you are interested in improving iso7816.c, then rewrite the select_file function. It is not very generic. For example it won't work for my german debit card, which is of course iso-compliant. Also get_data/put_data could be implemented. @ep: APDUs with Class Byte 0x80 are very misplaced in an iso-driver. I guess that this was an accident. > >> I guess #237 would solve the problem almost cleanly for you. > >> > >> I remember a similar problem with Estonian ID card but after some digging > >> in the specs and card manual it turned out to be somewhat sensible (Maybe > >> something like 0x00 Le indicating "give me as much as you have", like in > >> deciphering comments) but I can't locate the details nor changesets about > >> it now. > > > > This was the right hint – I hadn't thought of that. :) > > > > Even though certainly no data is expected from the card when issuing a > > MSE command, I switched to a Case 2 APDU with Le = 0. The transmitted > > APDU is exactly the same (P3 set to 0), and I think that leaving room > > for a small buffer on the stack is a less ugly workaround than > > disabling the check logic in apdu.c. So the driver can live without > > #237 :) > Glad I could help. The transmit_bytes solution would also be nice but > unfortunately the patch did not compile and I don't know the use case of > ticket poster well enough to decide on the right approach (transmit to a card > or transmit to a reader...) > > > The revised patch is now at > > http://www.opensc-project.org/opensc/attachment/ticket/177/itacns-patch4.diff > > , and I feel it addresses all points that have been brought up. > Yes :) > > Some things to consider > * javacard driver really should be the last but one driver before default. > It is as dummy by nature as the default driver. > * card->name vs driver->name. Currently the card driver name is long and in > Italian ("Carta Nazionale dei Servizi") while the card name is short and in > English. Keep in mind that the driver name is hidden from most users and the > card name pops up with opensc-tool -n and in your case in PKCS#11 token > labels. You might want to balance between them, as long as OpenSC does not > have localization support. > * Also, you use the card name as the PKCS#15 card label. From personal > experience I'd suggest to use something personal instead of that, so that > Firefox or thunderbird could differentiate between two cards of the same > type. For the Estonian ID-card it used to be "ID-kaart" as well, but "MARTIN > PALJAK (PIN1)" prompt beats "ID-kaart (PIN1)" prompt. > > Can I go ahead and commit it? _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
