Storing key on multiple smartcards
gniibe at fsij.org
Fri Apr 19 03:44:49 CEST 2019
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
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.
More information about the Gnupg-devel