OpenPGP card specification: Data Object of 0x7f21 ("CERT-3")

[NIIBE Yutaka]

On 2011-12-21 at 09:46 +0100, Achim Pietig wrote:
> data length of 2048 and more are still common in actual smart cards.
> E. g. the next german health card (eGK v2) comming in 2012 has a
> requirement of 2048 bytes for sending and 64K for receiving in a
> single command.  Most actual card readers under PC/SC (e. G. SCR
> 3310/335) have no problems with these data length.

Thanks for your comment.  Your comment gives me an opportunity to
think about communication between host PC, card reader, and card.

For implementation of Token, I thought that it would be good to
support extended APDU level exchange (only), from the view point of
for host PC software.  But I think that it might not be better way,
because the world is not only for Token, but card reader + card is
common.

For me, command chaining and/or GET RESPONSE looked quite awkward way
of communication at application level.  I thought that it's much simpler
using lower level way to handle merging packets by extended APDU level
exchange.

If there were only tokens in the world (I mean, no card reader + card
combination), it would be.  However, considering card reader + card
combination, it is not the "application level" sometimes, but
communication between card reader and card.

> If the ccid-driver and the pcsc-wrapper have still such limitations,
> there is a need to extend them soon!

The limitations are only valid for extended APDU level exchange.

> The next version of the OpenPGP card will support even more
> certificates with these length.
[...]
> I will not support transparent EFs, it's a pre-historic technic ;)

In the current standard of ISO 7816, DO handling just supports data as
a whole.  While it might be questionable using EF, READ BINARY or
WRITE BINARY supports partial data access on the card using offset.
That's the reason, I said using EF might be better for big data.  But,
it's not that such big in fact, 8KiB at maximum.

So, I wonder if I will support some big data (such as trust db and
public keyring) on Token in the way of ISO 7816, or another way.  For
token implementation, it is possible, say, to support USB Mass Storage
Class, which might be better for big data.

Thanks again for your valuable input.
--