What should '--local-user' mean when multiple secret keys match?

[Dashamir Hoxha]

I find this discussion interesting. Thanks for sharing your experience.
I have a suggestion that you might have missed, which I describe below.

On Tue, Jan 29, 2019 at 12:15 AM Daniel Kahn Gillmor <dkg at fifthhorseman.net>
wrote:

> I'm in the middle of a key transition, so i'm uncovering several places
> where there's some awkwardness.
>
> I want people to be able to move to a new OpenPGP certificate, without
> completely disabling their old certificates, and still being able to
> cope with a world where people rely temporarily on their old certs in
> some contexts.
>
> I recently ran into the situation where i was using git to sign a tag.
>
> "git tag" uses --local-user with a User ID constructed from the git
> committer identity.  GnuPG uses that string to pick the secret key that
> has a matching user ID and is signing-capable.
>
> Here were my two keys, in the order emitted by "gpg --list-secret-keys":
>
> A * oldprimary [signing,certification] (created 2007)
> B   - matching User ID
> C   - subkey [signing] (created 2018)
>
> D * newprimary [certification] (created 2019)
> E   - matching User ID
> F   - subkey [signing] (created 2019)
>
> gpg chose to sign with C.
>
> I wanted it to sign with F.
>
> Now, i know *some* workarounds to convince gpg into signing with F based
> on --local-user, but they all have downsides.  In the interest of trying
> to figure out a better user experience for people who *don't* know (and
> don't want to have to learn) all of these workarounds, i'll note what i
> came up with:
>
>  0) i could explicitly set git's user.signingKey field to the
>     fingerprint of the new OpenPGP certificate.
>
>     Downside: this doesn't scale well to multiple tools.  If i do this
>     here, then presumably i have to do it in every tool that uses GnuPG.
>     This would make future key transitions much more difficult, because
>     i'd have to track down every place i've stashed the fingerprint.
>
>  1) i could disable A entirely using "disable" from gpg --edit-key
>
>     Downside: this disables the entire key, afaict, which is more than i
>     want to do.
>
>  2) i could re-order the keys in my GnuPG keyring so that newprimary
>     comes first.
>
>     Downside: this is tricky, as it involves deleting the old
>     certificate and re-adding it later.  It has issues with maintaining
>     ownertrust, secret key material, and non-exportable certifications
>     if you do it wrong.  is there an easy/safe way to do this?
>
>  3) i could remove the signing-capability on A, and change C's
>     expiration date to "now".
>
>     Downside: Let's assume that i've published such a change. Removing
>     the signing-capability from the primary seems like it might cause
>     problems for signatures made with A in the past (i haven't tested in
>     detail), and it limits my ability to use C during the transition,
>     should i need to do so in some contexts (e.g. peers that don't know
>     about my new certificate yet).  This also requires the use of
>     "change-usage", which is not even documented in "help" in "gpg
>     --edit-key"
>
>  4) Back up and delete the secret keys from
>     ~/.gnupg/private-keys-v1.d/*.key that correspond to keys A and C.
>
>     Downside: This limits my ability to use A or C during the transition
>     phase if i want to use them -- it's more cumbersome to have to
>     restore them from backup.  It also depends on my understanding the
>     contents of ~/.gnupg/, which has traditionally been outside the
>     "API" of GnuPG.  Do we really want to encourage users tinkering
>     around in there?
>

5) Backup the whole GNUPGHOME, like this: `cp -a ~/.gnupg ~/.oldgnupg`
     Make sure that you have only one secret key on each GNUPGHOME
     (the old key on ~/.oldgnupg, and the new one on ~/.gnupg).
     You could have done the backup before generating the new key, to make
     things easier. With this setup you normally would use the new key, but
if you
     want to use the old one for some reason, you could prefix the command
with
     `GNUPGHOME=~/.oldgnupg some-command . . . . .`
     Or you can run `export GNUPGHOME=~/.oldgnupg` on a new terminal window,
     and afterwards start the program that you wish to use.

I am not sure how well this would work for your case, but this is just
another possible
solution. From my experience (and meditation) I have arrived in the
conclusion that
usually it is better to keep only one secret key per context (or
GNUPGHOME), and to
change the context whenever you need to use a different key.


>
> So, how could GnuPG make this decision more correctly and safely by
> default for normal users who want to transition in an orderly fashion to
> a new key?  A couple ideas:
>
>  * sign with the most recently-created key available.  (does this mean
>    we're looking at the age of the primary, or of the subkey?)
>
>  * provide explicit prioritization mechanisms between these keys that
>    are easy to use and easy to revert
>
>  * allow locally disabling subkeys independently from primary keys, or
>    even disabling key usage flags on the primary key.
>
> Any other suggestions?  what have i missed?  What should GnuPG do to
> handle this use case better?
>

Maybe GnuPG should do something to improve the handling of GNUPGHOME,
if there is something to be improved about it.

Dashamir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190129/c23459ca/attachment-0001.html>