Mailing List Archive

What should '--local-user' mean when multiple secret keys match?
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
Re: What should '--local-user' mean when multiple secret keys match? [ In reply to ]
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@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
Re: What should '--local-user' mean when multiple secret keys match? [ In reply to ]
On 28/01/2019 23:14, Daniel Kahn Gillmor wrote:
> 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?)

I think "Most recent valid subkey of the most recent valid primary key"
is a sensible default. "Most recent valid subkey no matter how old the
primary is" would be the other option, but I can't imagine a use case
where it would be preferable.

> * provide explicit prioritization mechanisms between these keys that
> are easy to use and easy to revert

This would be useful for advanced users, but probably overkill for most.

> * allow locally disabling subkeys independently from primary keys, or
> even disabling key usage flags on the primary key.

Changing the usage flags on the primary has been a longstanding feature
request, but if your first two suggestions were implemented it wouldn't
be necessary for this use case.

--
Andrew Gallagher
Re: What should '--local-user' mean when multiple secret keys match? [ In reply to ]
See inline please.

Sent from my test iPhone

> On Jan 29, 2019, at 07:45, Andrew Gallagher <andrewg@andrewg.com> wrote:
>
>> * sign with the most recently-created key available. (does this mean
>> we're looking at the age of the primary, or of the subkey?)
>
> I think "Most recent valid subkey of the most recent valid primary key"
> is a sensible default. "Most recent valid subkey no matter how old the
> primary is" would be the other option, but I can't imagine a use case
> where it would be preferable.

I think both scenarios are valid. I agree with your default. Perhaps, a config option to switch to the other...?


>> * provide explicit prioritization mechanisms between these keys that
>> are easy to use and easy to revert
>
> This would be useful for advanced users, but probably overkill for most.

So, most users would not change the default prioritization, and the advanced ones would have a convenient tool in hand. (Sotto voce: I strongly suspect there are more advanced users of GnuPG, than the "normal" ones.)

>> * allow locally disabling subkeys independently from primary keys, or
>> even disabling key usage flags on the primary key.
>
> Changing the usage flags on the primary has been a longstanding feature
> request, but if your first two suggestions were implemented it wouldn't
> be necessary for this use case.

I would still want very much to be able to change Usage flags on the primary. Regardless of whether the other good suggestions are implemented.
Re: What should '--local-user' mean when multiple secret keys match? [ In reply to ]
On 29/01/2019 14:03, Uri Blumenthal wrote:> See inline please.
> I would still want very much to be able to change Usage flags on the
> primary. Regardless of whether the other good suggestions are
> implemented.

I think that functionality is already implemented, though not
documented AFAIK. This is Debian stable:

--8<---------------cut here---------------start------------->8---
$ gpg --edit-key [...]
gpg (GnuPG) 2.1.18; Copyright (C) 2017 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

sec rsa2048/[...]
created: 2017-06-21 expires: 2019-06-21 usage: SC
trust: never validity: unknown
ssb rsa2048/[...]
created: 2017-06-21 expires: 2019-06-21 usage: E
[ unknown] (1). [...]

Changing usage of the primary key.

Possible actions for a RSA key: Sign Certify Encrypt Authenticate
Current allowed actions: Sign Certify

(S) Toggle the sign capability
(E) Toggle the encrypt capability
(A) Toggle the authenticate capability
(Q) Finished

Your selection?
--8<---------------cut here---------------end--------------->8---

By the way, the way I understood dkg's

> * allow locally disabling subkeys independently from primary keys, or
> even disabling key usage flags on the primary key.

was as not /changing/ usage flags (as already implemented), which is an
externally visible action that changes how other people use your pub
key, but rather a /local/ configuration that disables local access to
functionality. I.e., it will not be considered to have a certain usage
by GnuPG even though the public key that is shared with others does
actually have that flag.

HTH,

Peter.

--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>
Re: What should '--local-user' mean when multiple secret keys match? [ In reply to ]
On Tue 2019-01-29 11:19:59 +0100, Dashamir Hoxha wrote:
> Make sure that you have only one secret key on each GNUPGHOME
> (the old key on ~/.oldgnupg, and the new one on ~/.gnupg).

Thanks, this is definitely another functional workaround that i could
probably do in some contexts, but i can see how it would be difficult
for a novice user (someone who doesn't even know what environment
variables are). And it could also be problematic for (for example) a
mail user agent, which is receiving mail that is encrypted to both the
old key and the new key. Which GNUPGHOME should that mail user agent be
pointed to in order to handle incoming mail? (not to mention accessing
historical mail archives)

> 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.

This is a super interesting observation. Do other people have the same
experience? it seems to me that keeping the public keyrings in sync
alone would be a fair amount of hassle. Can you describe any other
scenarios where that might improve the user experience? I want to
really focus on making it easy for even a non-technical user to do
sensible things easily, in particular here: a planned, phased-in,
non-sudden key transition. Can you give other examples of where the
separated secret keyring is concretely useful and usable?

--dkg
Re: What should '--local-user' mean when multiple secret keys match? [ In reply to ]
On Thu, Jan 31, 2019 at 11:33 PM Daniel Kahn Gillmor <dkg@fifthhorseman.net>
wrote:

>
> > 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.
>
> This is a super interesting observation. Do other people have the same
> experience? it seems to me that keeping the public keyrings in sync
> alone would be a fair amount of hassle. Can you describe any other
> scenarios where that might improve the user experience? I want to
> really focus on making it easy for even a non-technical user to do
> sensible things easily, in particular here: a planned, phased-in,
> non-sudden key transition. Can you give other examples of where the
> separated secret keyring is concretely useful and usable?
>

Suppose that one wants to use a secret key to communicate with colleagues,
another one to communicate with friends, and another one to communicate
with his family. If he keeps all the secret keys and all the public keys on
the same addressbook (or keyring), it is possible that sometimes he may
make mistakes and use the wrong key for decryption and signatures. If they
are kept on separate contexts (or separate keyrings, or addressbooks) the
possibility of mistakes may be smaller.

In general, if you need to have more than one secret key (for any reason),
it seems to me more complicated, confusing and error-prone to keep them in
the same keyring than to keep them on separate keyrings (contexts).

Dashamir