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

[Daniel Kahn Gillmor]

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?

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?

    --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20190128/1445d8bf/attachment.sig>