Using OpenPGPcard through PC/SC service and with reader of Short APDU level exchange only

[NIIBE Yutaka]

On 2013-03-26 at 09:34 +0900, NIIBE Yutaka wrote:
> I'm looking the bug report:
> 
> 	https://bugs.g10code.com/gnupg/issue1405
[...]
> I think that this bug could be solved, if we improve app-openpgp.c.

Currently, GnuPG determines using extended APDU or not, only by the
information of the card.  When the card supports extended Lc/Le, GnuPG
will use extended APDU level exchange, even if the reader does not
support it.  To support this case correctly, we will require some
rework.

It's not that important for the community/users, perhaps.  Or it would
not be worth for the rework.  That's because there is just a few
readers in industry which support "Short APDU level exchange only",
and it still won't work well with OpenPGP V2 card for RSA >= 2048-bit
keys.  OpenPGP card V2 doesn't support command chaining, which is
required for "short APDU only" communication, when APDU is large.
(Singing will work as APDU is not need to be large, but it won't work
for writing keys to card and for decryption.)

Anyhow, this is very important lessen (at least, for me), to consider
smartcard related technology.

The CCID specification is not that good, for this specific case, and
we need to care about both of the reader and the card in the
application layer.

Perhaps, the recognition of the word, APDU, as an "application" layer,
would be wrong for correct programming.  Since APDU construction
should be adjusted by the constraints of the reader and the card, it
is better to consider APDU as a lower layer packet to be hidden from
the application.

In better API, application would only specify CLS-INS-P1-P2, and DATA,
not composing APDU by itself.  It would be lower layer which composes
APDU.
--