On 9/22/2010 5:59 PM, Andre Zepezauer wrote:
> On Wed, 2010-09-15 at 19:33 +0200, Andre Zepezauer wrote:
>> On Wed, 2010-09-15 at 11:43 -0500, Douglas E. Engert wrote:
>>>
>>> On 9/15/2010 6:30 AM, Martin Paljak wrote:
>>>> Hello,
>>>> On Sep 15, 2010, at 12:12 PM, Viktor TARASOV wrote:
>>>>>> Not yet! I had to replace line 122 of iso7816.c
>>>>>>> assert(count<= card->max_recv_size);
>>>>>> by
>>>>>>> assert(count<= card->max_recv_size>0 ? card->max_recv_size : 256);
>>>>>>
>>>>>> And then everything worked as expected.
>>>>>
>>>>> The same concerns 'max_send_size'.
>>>
>>> Some more concerns! The max_*_size code was working, but now
>>> we are making change to equate 256 = 0. Its not clear to me what is the
>>> problem.
>>>
>>>
>>> I would suggest that max_recv_size and max_send_size are always> 0, and
>>> if using extended APDUs, could be> 256.
>>>
>>> The only place where 0 implies 256 is in a short APDU, and that is
>>> handled by apdu.c as it builds the APDU to be sent and it is not using
>>> the max_*_size
>>> parameters.
>>>
>>> So I would like to suggest that we go back to 0.11 and look closer at
>>> the original problem, and solve it without having to treat 0 == 256.
>>
>> I have to agree, because the whole max_*_size magic is unnecessary
>> altogether. For example max_recv_size is only limited by the size of the
>> receive buffer. And this can vary. An excerpt from 7816-3:
>>
>> "Number Lr (length of response data) is the number of bytes present in
>> the data field of the response APDU. [...] ***Number Lr shall be in the
>> range zero to number Le.***"
>>
>> Therefore the only check required on sending APDUs is: Le<= sizeof(buf)
>> If there is nobody, who is able to state a real requirement on
>> max_recv_size, it could be removed from the code completely.
>>
>> On the other hand, the constraint max_send_size is actually required by
>> some cards. But this could be handled in lower layers too. For example
>> apdu.c could use chaining if Lc> max_send_size.
>
> The meaning of max_recv_size is still unknown to me. Could someone
> explain it to me, please. Btw, one of these changes has broken 2048b
> keys for CardOS. It may be caused by the fact, that 2048b keys (and
> corresponding cryptograms) are exactly 256 byte in size.
I two ran in to a problem with the card-piv.c because of this.
It now appears that max_recv_size = 0 implies unlimited length, but
should depend on if the card supports extened APDUs and an extended APDU is
being requested,
What I would think it should mean is 256 for short APDUs and 65536 for extened.
Code in card-piv.c which used to have:
apdu.le = (card->max_recv_size <= rbuflen)? card->max_recv_size : rbuflen;
apdu.resplen = rbuflen;
Was changed to:
apdu.le = (card->max_recv_size > 0 && card->max_recv_size <= rbuflen)?
card->max_recv_size : rbuflen;
apdu.resplen = rbuflen;
But this would then set apdu.le = rbuflen even if > 256.
This fixed the problem, with short APDUs.
if (card->max_recv_size == 0 && rbuflen > 256)
apdu.le = 256;
else
apdu.le = (card->max_recv_size > 0 && card->max_recv_size <=
rbuflen)? card->max_recv_size : rbuflen;
apdu.resplen = rbuflen;
Newer cards can support APDUs, (I don't have one to try) so the code
will need to be changed again to use extened APDUs.
The problem is the card driver is setting both apdu.le and apdu.resplen based
on max_send_size = 0;
Other drivers and yours might have a similar problem.
>
>
--
Douglas E. Engert <deeng...@anl.gov>
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
