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

[Achim Pietig]

Hi,

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.

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

The next version of the OpenPGP card will support even more certificates with these length.
I have several requests for even bigger storage, if the I/O buffer of the card hardware is not able to support it,
command chaining can be used, maybe I will support this in the next version also.
The content of a certificate DO is not limited to X.509, it is possible to store CV-certificates and proprietary formats as well,
it depends on the application.

I will not support transparent EFs, it's a pre-historic technic ;)
Next version of ISO 7816-4 has many extensions for working with DOs (including keys and passwords) and I'm working on a card OS without
any EFs.

Regards,
Achim


Am 21.12.2011 04:24, schrieb NIIBE Yutaka:
> Hi,
> 
> This is my comment for OpenPGP card specification version 2.0, with
> regard to Data Object 0x7f21, according to my experience of developing
> Gnuk.
> 
> In short, Data Object 0x7f21 ("CERT-3") is difficult to support.
> 
> If I understand correctly, this data object supposed to have X.509
> certificate for authentication key "OPENPGP.3".
> 
> The size of this data object is big, from the viewpoint of smartcard.
> When I created my certificate with cacert.org, its length is 1328 byte
> (for my RSA 2048-bit key for authentication).  I think that it can be
> bigger.
> 
> While other data objects are small enough (< 256 bytes), this data
> object is exceptionally big.
> 
> Current of GnuPG for exended APDU level cannot handle such a big data
> object.  This is true for internal ccid driver as well as for PC/SC
> backend.
> 
> For ccid driver, it's ccid-driver.c:ccid_transceive_apdu_level, which
> has smaller buffer.  For PC/SC backend it's
> pcsc-wrapper.c:handle_transmit which has 1024-byte buffer.
> 
> I wonder to change ccid-driver.c and pcsc-wrapper.c just for the data
> object 0x7f21.  So, I have investigated if there are some use case for
> this data object.  I had thought that it were used by Scute and Poldi,
> but I couldn't find any use case in the code.
> 
> In my opinion, it would be better to define EF (elementary file)
> instead of DO for large data, so that it can be accessed by
> READ_BINARY and WRITE_BINARY.