USB CCID issue

[NIIBE Yutaka]

On 01/27/2016 06:51 AM, Jan Suhr wrote:
> The issue ticket is here:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775559

What I saw here is:

    http://pcsclite.alioth.debian.org/ccid/readers/Nitrokey_Storage.txt

    dwMaxCCIDMessageLength: 271 bytes

... which is common value for reader/token implementations.

Today, in your message it says:

    dwMaxCCIDMsgLen        48

That's quite unusual value.

If it's under development, I'd understand the situation.  After you
ship to users, please control your version of firmware.  It confuses
(at least) me.

> Could someone with better knowledge of the GPG stack help to
> localize the root cause?

For internal ccid driver of GnuPG, it cares the value of
dwMaxCCIDMessageLength, only for extended APDU level exchange.
Current code doesn't check dwMaxCCIDMessageLength for TPDU level
exchange.

It seems for me that your firmware of Nitrokey Storage tries to avoid
buffering (just using 64-byte buffer of USB directly) and expects host
PC to handle things (kindly on behalf of the device).

Well, once in 2010, when I was learning USB function implementation, I
had tried like that.  I was wrongly considered that simpler
implementation of USB stack on device side is better.  For the record,
you can see (dwMaxCCIDMessageLength = 64) in:
    http://pcsclite.alioth.debian.org/ccid/readers/Fsij_gnuk.txt


I think you also have some reason(s) (possibly, different than me) to
have this value and avoiding buffering.  But, I sincerely recommend to
support buffering in your firmware, as almost all device
implementations do, and let it have usual value like 271 for
dwMaxCCIDMessageLength.  Or else, it means that you have to take your
own risk to ask modification of CCID software on PC.
--