Chaskiel M Grundman wrote:
--On Tuesday, March 20, 2007 08:23:32 AM +0100 Andreas Jellinghaus
<[EMAIL PROTECTED]> wrote:
what about code like this in card-flex.c:
The error did not occur in card specific code. You cannot send a short
apdu with lc == 256 to any card.
Yes I agree with the Lc=255 256 was a mistake. The apdu chaining
code takes care of chaining for the PIV card, as the chaining uses 255.
What I was implying that even setting the max_send_size to 255
might not work with all cards, as the *previous* limits were
CHOP 248 (I believe) and the opensc.conf has 252(?) for PC/SC.
sc_update_binary() uses card->max_send_size to cap its lc.
on cryptoflex, card->ops->update_binary is iso7816_update_binary.
that would break some cards again, if I understand the situation
correctly.
What cards?
The other cards that (I don't have) that don't do anything to set a
limit on the max_*_size may have problems. Is CHOP the limit?
Is it by accident that they have worked in the past with the CHOP
limit, or the limits in the opensc.conf?
These are the other drivers I see that may need changes, if they
can't handle max_send_size=255, max_recv_size=256:
card-acos5.c, card-atrust-acos.c card-belpic.c, cardos.c,
card-incrypto34.c, card-jcop.c, card-mcrd.c, card-oberther.c,
card-setcos.c, card-tcos.c
The references to max_send_size are:
Initialization in sc_connect_card
Chunking in sc_write_binary and sc_update_binary
Applying size limits in card-gpk.c card-miocos.c and card-starcos.c
asserts in iso7816_write_binary and iso7816_update_binary
Is there a card that will lose if sc_update_binary breaks things up into
chunks of 255 instead of 256? if so, it doesn't really have "binary"
files, now does it?
The Lc=256 was a mistake. its 255.
And no it does not have "binary" files. It has objects. and it write them
using chaining as per: NIST-800-73-1 defined APDUs.
The General Authenticate APDU could send more the 255 bytes, and expect
more the 256 back. Uisng chaining to write, and 61xx with get response
to read.
Where some PIV cards have had a problem is with the returning 6100
and the GET RESPONSE reading on 248. The card expected to provide
256 bytes and another 6100, looping till the last returned 61xx
to get the last xx bytes.
_______________________________________________
opensc-devel mailing list
[email protected]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
--
Douglas E. Engert <[EMAIL PROTECTED]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
_______________________________________________
opensc-devel mailing list
[email protected]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
