Storing key on multiple smartcards

[NIIBE Yutaka]

Hello,

I was not able to catch up, because I didn't receive Peter's two
messages on April 10th, for some reason.  I am reading those messages in
the archive.

Frederick Zhang <frederick888 at tsundere.moe> wrote:
> May I know what your thoughts are on this issue? I understand my changes
> to finish_lookup seem to have some unnecessary impacts on other logic,
> e.g. public key query, so maybe we should tweak the current
> build_sk_list to detect smart cards regardless of locusr?
>
> And what did you think of my "different keygrips for different cards"
> solution for the "same subkey on multiple cards" problem? Did it sound
> good to you?
>
> By the way, I reckon Peter has made some solid points about the warning
> message and the additional option for keytocard command. Do you think we
> should get this implemented first?

Sorry, I can't understand how your patch solves your particular problem.
Let me focus on "same subkey on multiple cards" problem.

IIUC, it is related to how we can consider an identity of a card and how
we manage its raw key materials inside.  (I think that it is more than
"UI improvement" issue.)

There is an assumption in the current implementation of gpg-agent, a key
material can be on disk or in a single card.

Our discussion is how we can relax this assumption.

Once, I had a practice to have multiple cards with same serial number,
so that I worked around the situation like you.  Obviously, this
violates an assumption (perhaps, very important one), of smartcard
administration.  At least, it can't be recommended.

Perhaps, better approach would be using a serial number only as a hint,
extending keygrip-centric approach of gpg-agent.  It would be good to
administrate the hint information editable by user.  Showing the serial
number to ask insertion of a card... is not helpful so much to a user.
It is more helpful when a user can name the card by some nickname.

For warning message at keytocard command, I think that Peter's
suggestion makes sense, but please don't mix separate things.  It is
related somehow, but I think it is better to be handled seperately.
--