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