Supporting fixed length keypad input

[Achim Pietig]

Hi,

some remarks in the text below:

Am 10.01.2013 02:03, schrieb NIIBE Yutaka:
> On 2013-01-09 at 10:23 +0100, Werner Koch wrote:
>> I don't consider this a real problem.  The minimum length is anyway 6
>> and thus there is not much of an advantage to notice that a larger PIN
>> length.  We have at max 6 tries.
> 

You have only 3 tries for each PIN/password.

> OK.  I will consider to support getting/putting user's preference from
> the login-data DO.
> 

Login-Data is an ISO definied data object (7816-6).
It should not contain other information than defined by ISO, so first check if this information is possible there.

>>> I meant two things.  It seems that it's only through GPG-Agent which
>>> SCDaemon could get such information from user.  And, GPG-Agent could
>>> cache information of user interaction to stop asking user every time.
>>
>> Hmmm, that might be possible but I still don't like it.
> 
> Perhaps, I had thought over-engineered thing, which would be
> unnecessary.  This particular idea of mine came when I looked your
> commit of the following:
> 
> 	commit b817ae7df947093384a25797999a9aa187e20f9c
> 	Author: Werner Koch <wk at gnupg.org>
> 	Date:   Tue Feb 7 14:17:33 2012 +0100
> 
> 	agent: Add pin length field to the shadowed private key format.
> 
> I thought that you had intended to cache PIN length information
> together with card S/N in user's shadowed secret key, under control
> of GPG-Agent.
> 
> Yes, simpler is better.  I won't implement the caching by GPG-Agent.
> I will just implement proxy things by GPG-Agent from SCDaemon to
> pinentry/gpg, only when needed.
> 
>>>     NOTE: There are cases when user doesn't want to use the card
>>>     reader's keypad.  For example, his PIN includes characters not
>>>     available by the reader's keypad.
>>
>> --disable-pinpad comes hadny in this case.  The case to too rare to
>> annoy a user with a prompt on whether to use the pinpad.  However, we
>> can put an URL into the "please enter your pin at pinpad" pop up
>> messages so that the user will be able to find out what to do in cases
>> he has not only digits in his PIN.  I consider a URL better than a fixed
>> text due to getext issues and an easier way to update this information.
> 
> Currently, it is SCDaemon which has "--disable-keypad" option.  I
> think that it is an option for a card reader, not for particular card
> usage.  When user knows his card reader doesn't support pinpad input
> well, he will use this option to stop the card reader's feature.  Once
> it is disabled, a user needs to restart SCDaemon to enable use of
> keypad.
> 
> I think that we need an option for gpg to enable/disable use of keypad
> for particular card usage.  SCDaemon would inquire this option to gpg
> through GPG-Agent.  Or, gpg would inform SCDaemon through GPG-Agent.
> 
> BTW, we need to decide wording for "keypad" or "pinpad".  I don't
> have any preference.  I tend to use "keypad" because there are
> functions implemented with _keypad suffix, but "pinpad" would
> be better as it looks more common word.
> 

"pinpad" is the most common word in standards.

Generell:
If support for "old" readers with fixed length input is requirerd, I prefere a local var (e. g. gpgconf) with the fixed length preferred by the user.
If the var is 0 or not defined, the min-max length should be taken from the card. The var may be evaluated by pinentry.
If the password is defined by a keyboard, --disable-pinpad may be useful.
All this affects the local environment only.

Actual there are 3 standards for readers with PIN-pad, all support var-lenth-pins, so older readers will be obsolet soon.
If you want to support this old items anyway, then keep it simple...
It makes no sence to me to find a solution with new information in card or servers etc. to make this run at any pin-pad - standard compliant pinpads will run with min-max values!

Regards,
Achim