Openpgp card handling depending on manufacturer?

Klaus Flittner klaus at
Mon Nov 5 08:34:14 CET 2012

NIIBE Yutaka <gniibe at> wrote:

> All that I can find is the following.
> Start from line 3809 of gnupg/scd/app-openpgp.c:
> ---------
>       /* Some of the first cards accidently don't set the
>          CHANGE_FORCE_CHV bit but allow it anyway. */
>       if (app->card_version <= 0x0100 && manufacturer == 1)
>         app->app_local->extcap.change_force_chv = 1;
> ---------

This was also the only part i found. But it only applies to version 1
of the card and manufacturer value of 1. 

> It would be good to your check smartcard reader and ATR string of the
> card.

I will try to get a different smartcard reader and see if it is somehow
related to the reader.

> Even when key generation at the card takes more time, there is a
> protocol which extends timeout by the smartcard reader (the time
> extension request).  GnuPG USB communication doesn't timeout when the
> smartcard reader uses this protocol.
> If it means the whole process, 10 seconds timeout for key generation
> operation of RSA 4096-bit key sounds short for me.  It is no surprise
> for me that it takes, say, 30 seconds.

The generation of these keys takes considerably longer than 10 seconds.
The longest i've seen till now was 500 seconds. The card sends an time
extension request and it is (at least sometimes) used to extend the
timeout, as the same card with the same firmware and just a changed
manufacturer value generates the keys without an timeout occuring.

The only difference between the working and non-working case is the
manufacturer value. And as far is i understand the only software in the
chain (reader firmware, libccid, pcsc, gpg) that uses this value or
even now about it is gpg.

Klaus Flittner

More information about the Gnupg-devel mailing list