Storing key on multiple smartcards

Frederick Zhang frederick888 at tsundere.moe
Thu Apr 18 09:47:04 CEST 2019


Hi NIIBE,

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?

On 11/4/19 12:42 am, Peter Lebbing wrote:
> On 10/04/2019 16:22, Frederick Zhang wrote:
>> So I strongly agree keytocard should, even by default, leave the
>> originals untouched, and perhaps instruct users to move the keygrip to a
>> safe place afterwards.
> 
> People move their keys to a card because they do not want the key to be
> on disk for whatever reason. Leaving them on the disk by default might
> be surprising to them and potentially harmful.
> 
> I'd rather propose that the default is that "keytocard" shows a warning
> message:
> 
> | Warning: moving the key to card will remove it from disk. It is not
> | possible to get the private key out of the card again. If this is not
> | what is intended, supply the '--keep' option to 'keytocard' to keep the
> | key stored on disk as well. Continue? (y/N)
> 
> And obviously that option needs to be implemented as well. This is just
> a first setup for the precise message to convey my intention.
> 
> Everybody should have a backup of their encryption key, but still,
> throwing it away when the user might not expect it on 'keytocard' might
> be a bad idea (this is what we do now!). Primary keys are not quite as
> bad as that, but still.
> 
> HTH,
> 
> Peter.
> 

-- 
Best Regards,
Frederick Zhang

Email:      frederick888 at tsundere.moe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190418/9227de12/attachment.sig>


More information about the Gnupg-devel mailing list