Supporting fixed length keypad input

[NIIBE Yutaka]

Thanks for your comment.  I reconsidered.

On 2013-01-08 at 15:50 +0100, Werner Koch wrote:
> On Tue,  8 Jan 2013 09:31, gniibe at fsij.org said:
> 
> > (1) Add a option to SCDaemon.  Say, "opt.keypad_fixed_length" or
> >     something.  This is to enable handling of fixed length keypad
> >     input for SCDaemon.
> 
> The problem here is that you may not know the length of the PIN.  The
> card may have been used before with a different reader.  Depending on
> the implementation of the reader the wrong PIN counter may soon go down
> to zero.  An explicit agreement from the user will be better.

I see.  Yes, the PIN can be changed with a different environment.

> Or wait: We could extend the login data flags
> (app-openpgp.c:parse_login_data) to declare that the length of the pin
> is 6/8.  Only if that flag has been set the fixed length feature may be
> used.

This would be a place to save the information, but this information is
available to everyone who can accesses the card, that would not be
good.

> (2) Add protocol between SCDaemon and GPG-Agent.  SCDaemon inquires
> >     length of PIN to GPG-Agent, when needed.
> 
> gpg-agent should not know about such card or reader details.

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.

Now, I understand the risk of caching wrong information to cause
decreasing PIN counter to zero.

> > (3) Upon inquiry by SCDaemon for the length of PIN, GPG-Agent will
> >     answer if it has the information at hand.  Or else, GPG-Agent will
> >     invoke pinentry to ask the length to the user, and reply back to
> >     SCDaemon.
> 
> It would be okay to use gpg-agent as a proxy to pop up a pinentry.
> IIRC, we already do that in some cases.

Yes.

Perhaps, I was wrong that I began this discussion by implementation
detail.

Let's consider possible user interaction for keypad input.  I think
that the default interaction will be two steps.

(1) When authentication is required for the card and the card reader
    has a feature of keypad input, GnuPG asks a user about use of
    keypad.  If the card reader is not known to support variable
    length input, GnuPG asks length of PIN, too.

    If GnuPG knows the card reader supports variable length input
    (by an option or white list), it can omit asking length of PIN.

    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.

    GUI would be like this:

       +-----------------------------+
       | Do you use reader's keypad? |
       |                             |
       | Length of User PIN: [N  ]   | <-- This field is enabled for
       |                             |      fixed-length input
       |                 [Yes] [No]  |
       +-----------------------------+

(2) GnuPG sends command to the card reader for authentication with
    keypad and shows a dialog box to prompt user.

   +-------------------------------------+
   | Please enter the PIN                |
   |                                     |
   | Use the reader's keypad for input.  |
   |                                     |
   |                              [OK]   |
   +-------------------------------------+

    And a user inputs PIN with the card reader's keypad.


I'd like to propose adding the interaction of step (1) above, as a
default.  Next, we will consider how user can skip the step (1).

Thinking about the condition GnuPG can skip the step (1)....
Suppose we define three subconditions:

  (A) User specifies to force keypad input for the card.

  (B) GnuPG knows the card reader supports variable length input.

  (C) GnuPG knows the length of PIN.

Then GnuPG can skip the step (1) when (A && (B || C)) is true.
--