--On Monday, November 13, 2006 09:23:06 AM +0100 Andreas Jellinghaus
<[EMAIL PROTECTED]> wrote:
I have no clue: would that restrict them? i.e. take functionality away?
or would opensc only split one command into several smaller ones and thus
preserve functionality, but add more communication overhead and thus slow
down the process.
Not all commands can be split (e.g. perform security option)
Which generic reader classes we worry about? It seems to me that only
ccid class is an issue. If this is the case, would it be better to
special-case a few readers by their USB vendorID:prodID in ifd-ccid.c?
I'm not sure what the best way is myself. chaskiel indicated, he would
prefer opensc to deal with it. so not sure what to do.
Even if it was desirable, ifd-ccid.c cannot split an apdu into multiple
apdus without knowing the syntax and semantics of the APDU (consider the
file offset in UPDATE BINARY...)
It would be appropriate for the configuration & blacklist to come from
ifd-ccid.c, but opensc must do the actual work.
--On Sunday, November 12, 2006 11:02:44 PM +0100 Nils Larsch
<[EMAIL PROTECTED]> wrote:
I don't like this ... for example the result of a 2048 bit rsa signature
generation returns a 256 byte signature and hence restricting the max
receive size to 248 makes it complicated to read the signature with T1
card.
The ccid limitiation does not affect T=1 (*) as T=1 can break any apdu into
dwMaxCCIDMessageLength-10 sized chunks (dwMaxCCIDMessageLength-10 is only a
limit on IFSD and IFSC, not the total apdu size). Note that T=1 _always_
has to break up a 2048bit signature into multiple TPDUs
* unless the ccid reader works in "APDU mode" and runs T=1 itself. All the
apdu readers in pcsc-ccid's list have the large dwMaxCCIDMessageLength, and
so would not restrict anything.
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
