Chaskiel M Grundman wrote:
--On Tuesday, March 20, 2007 08:23:32 AM +0100 Andreas Jellinghaus
<[EMAIL PROTECTED]> wrote:
that would break some cards again, i
I suppose it would help if I read code out of the correct sandbox....
I think if I had written the piv stuff I would have maintained the
abstraction and done fragmentation and caching within piv_read_binary,
Yes, I could have done that. But the PIV reads and write
whole objects, you can not start in the middle.
The write is done by chaining of apdus , and the read
by get response looping over 61xx return codes.
So switching the values of the max_send_size and
max_recv_size between 0xffff (for the simpuated read/write binary)
and 255 and 256 for calls to sc_transmit made the code a
lot easier.
but I suppose this way works out ok.
How does SC_APDU_CHOP_SIZE affect piv anyway? it overrides
card->max_xxx_size in piv_init...
It was effecting the default in ctx.c for max_recv_size
and max_send_size prior to the chaining code being added in apdu.c
Some PIV cards expected to always return data in 256 byte chucks,
using 61xx. xx=00
It required the user to set max_send_size and max_recv_size
to opensc.conf.
In the more general case OpensSC should be able to look at the
reader, and the card and determine the max_send_size and max_recv_size,
but this requires looking closely at each card and its driver, as
each card may have its own limits. Maybe better left for 0.11.3.
ooh. this chaining stuff could be used to make
cryptoflex_compute_signature simpler.
Yes it does. Any other cards too?
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
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
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
