USB communication (current)
===========================

* Get response, command chaining, short APDU only.


If it were only for token and no smartcard:

* Get response, command chaining and short APDU would be considered
  useless.

* It would be wise to use extended APDU and CCID/ICCD block chaining.

The question would be: When lower layer (CCID/ICCD layer) support
enough mechanism of block assembly, why not use one in the application
layer (ISO 7816)?

For token implementation, CCID/ICCD would be lower layer and ISO 7816
would be higher layer, but it's different in fact.  The figure of
communication is like::

    host <-----------> reader <---------> smartcard
           CCID/ICCD           ISO 7816
    
    host <--> token

Given the situation host side (GnuPG) already has the features of
handling get response, command chaining, and short APDU only, it is
rather better to do that on token side too.

Besides, supporting extended APDU on host side, it would be needed to
prepare 64KB buffer (that's the maximum size), as there is no explicit
limitation for buffer size.  64KB would be large, and this could be
avoided when we use short APDU only.


USB communication (second attempt)
==================================

* No get response, no command chaining, but extended APDU and extended
  Lc and Le.  I think that this keep the code simple.

* The value of dwMaxCCIDMessageLength is 320, that's the size
  of header of ICC block plus size of maximum APDU (by 64
  granularity).  Still, some ccid implementation (ccid 1.3.11, for
  example) sends ICC block using chaining unfortunately, so we keep
  the code of ICC block chaining.


USB communication (initial attempt)
===================================

* Once in the past (version <= 0.4), the value of
  dwMaxCCIDMessageLength was 64 and we supported CCID/ICCD block chaining,
  so that we could not handle multple Bulk transactions.


OpenPGP card protocol implementation
====================================

I try to follow "no clear password(s)" policy, even if it is on
protected flash memory.  Further, keystrings for user and reset code
are removed after key imports.  Because of this, replacing keys are
not possible without password information.  (Thus, replacing existing
keys are not supported.)

Therefore, there is "no clear password" and "no keystrings" on flash
ROM when Gnuk is used by admin-less mode.  When it is used with admin,
the keystring of admin is on flash ROM.


How a private key is stored
===========================

KEYPTR
         ----> [   P   ][   Q   ][       N        ]
               <---encrypted----><---  plain  ---->

initial_vector (random)        16-byte
checksum_encrypted             16-byte
dek_encrypted_by_keystring_pw1 16-byte
dek_encrypted_by_keystring_rc  16-byte
dek_encrypted_by_keystring_pw3 16-byte

... decrypted to

[   P   ][   Q   ]
checksum 16-byte