stub-key migration from gpg 1.4/2.0 to 2.1

Kristian Fiskerstrand kristian.fiskerstrand at sumptuouscapital.com
Wed Feb 24 09:35:23 CET 2016


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 02/24/2016 09:08 AM, Werner Koch wrote:
> On Wed, 24 Feb 2016 02:25, gniibe at fsij.org said:
> 
>> I'd understand that extending gpg-agent to support importing stub
>> doesn't sound good.  Even so, I think that it's a developers'
>> view point.  For users, it's better not to be requested any user
> 
> Coincidentally I thought about this yesterday and I am pondering 
> with the idea of not requiring a stub key at all for a currently 
> inserted card.  That is actually the same thing we do in 
> command-ssh.c - the currently inserted card is treated specially
> by always trying to use it.
> 
> Sure this does not help if you need to juggle with a bunch of
> cards but the most common case is that there is just one card.

Are you sure about that?

> 
> On a somewhat related issue:
> 
> There is the request to handle the case where keys are stored on 
> several cards which we can't easily solve with the current system 
> at all (or well, only with a lot of nasty code).  I have two ideas 
> on how to handle this:

Isn't this case pretty much solved already if the first part is
implemented? At least if the stub data generated isn't stored
persistently but in a cache of some sort separate from the secret
keyring.

At least the use case where you'd switch from smartcard with only
subkeys (for daily use) to smartcard with a primary key (to certify
some certificates using a smartcard stored more securely) seems to be
void if the keygrip and cardno isn't stored as regular stub to begin
with.

- -- 
- ----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Public OpenPGP key at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- ----------------------------
Aquila non capit muscas
The eagle does not hunt flies
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJWzWtHAAoJECULev7WN52F+qkIAKAZaexAnRhpXl6cutq+htDd
8TMR0atrmZ5L3IGpTAtKLJTLmks1lc4DbJAmShZbh2U5/l0iK+4KpGDs1Lp2APC6
4UDrkuzzK5CwQ8Om8MpxLz0cJBZM4Pe+h1B5klvEnk2Skk0RuB4uWn8qcbRPfkE1
vYPOgfGCD9qNVi+g4wQtEWDpfX5QfKAEKDyZYIwmTSpzOI8GyFsMwjnS9CTxv2oB
5/ECUIlgYulcizsg8Gb+Hf7AknwFkKJW+Xd1uQKLiU+dtIRCauNQ5owiP1XYgYOj
2gKXW9zA6ix70DkRySUmTeB+Ilyjquc1d0+mo1P1+7giLrthL8+cpXUlSLY6LHo=
=Y/XZ
-----END PGP SIGNATURE-----



More information about the Gnupg-devel mailing list