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

Reply via email to