<div dir="ltr"><div dir="ltr"><div>I find this discussion interesting. Thanks for sharing your experience.</div><div>I have a suggestion that you might have missed, which I describe below.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 29, 2019 at 12:15 AM Daniel Kahn Gillmor <<a href="mailto:dkg@fifthhorseman.net">dkg@fifthhorseman.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I'm in the middle of a key transition, so i'm uncovering several places<br>
where there's some awkwardness.<br>
<br>
I want people to be able to move to a new OpenPGP certificate, without<br>
completely disabling their old certificates, and still being able to<br>
cope with a world where people rely temporarily on their old certs in<br>
some contexts.<br>
<br>
I recently ran into the situation where i was using git to sign a tag.<br>
<br>
"git tag" uses --local-user with a User ID constructed from the git<br>
committer identity. GnuPG uses that string to pick the secret key that<br>
has a matching user ID and is signing-capable.<br>
<br>
Here were my two keys, in the order emitted by "gpg --list-secret-keys":<br>
<br>
A * oldprimary [signing,certification] (created 2007)<br>
B - matching User ID<br>
C - subkey [signing] (created 2018)<br>
<br>
D * newprimary [certification] (created 2019)<br>
E - matching User ID<br>
F - subkey [signing] (created 2019)<br>
<br>
gpg chose to sign with C.<br>
<br>
I wanted it to sign with F.<br>
<br>
Now, i know *some* workarounds to convince gpg into signing with F based<br>
on --local-user, but they all have downsides. In the interest of trying<br>
to figure out a better user experience for people who *don't* know (and<br>
don't want to have to learn) all of these workarounds, i'll note what i<br>
came up with:<br>
<br>
0) i could explicitly set git's user.signingKey field to the<br>
fingerprint of the new OpenPGP certificate.<br>
<br>
Downside: this doesn't scale well to multiple tools. If i do this<br>
here, then presumably i have to do it in every tool that uses GnuPG.<br>
This would make future key transitions much more difficult, because<br>
i'd have to track down every place i've stashed the fingerprint.<br>
<br>
1) i could disable A entirely using "disable" from gpg --edit-key<br>
<br>
Downside: this disables the entire key, afaict, which is more than i<br>
want to do.<br>
<br>
2) i could re-order the keys in my GnuPG keyring so that newprimary<br>
comes first.<br>
<br>
Downside: this is tricky, as it involves deleting the old<br>
certificate and re-adding it later. It has issues with maintaining<br>
ownertrust, secret key material, and non-exportable certifications<br>
if you do it wrong. is there an easy/safe way to do this?<br>
<br>
3) i could remove the signing-capability on A, and change C's<br>
expiration date to "now".<br>
<br>
Downside: Let's assume that i've published such a change. Removing<br>
the signing-capability from the primary seems like it might cause<br>
problems for signatures made with A in the past (i haven't tested in<br>
detail), and it limits my ability to use C during the transition,<br>
should i need to do so in some contexts (e.g. peers that don't know<br>
about my new certificate yet). This also requires the use of<br>
"change-usage", which is not even documented in "help" in "gpg<br>
--edit-key"<br>
<br>
4) Back up and delete the secret keys from<br>
~/.gnupg/private-keys-v1.d/*.key that correspond to keys A and C.<br>
<br>
Downside: This limits my ability to use A or C during the transition<br>
phase if i want to use them -- it's more cumbersome to have to<br>
restore them from backup. It also depends on my understanding the<br>
contents of ~/.gnupg/, which has traditionally been outside the<br>
"API" of GnuPG. Do we really want to encourage users tinkering<br>
around in there?<br></blockquote><div><br></div><div>5) Backup the whole GNUPGHOME, like this: `cp -a ~/.gnupg ~/.oldgnupg`</div><div> Make sure that you have only one secret key on each GNUPGHOME</div><div> (the old key on ~/.oldgnupg, and the new one on ~/.gnupg).</div><div> You could have done the backup before generating the new key, to make</div><div> things easier. With this setup you normally would use the new key, but if you</div><div> want to use the old one for some reason, you could prefix the command with</div><div> `GNUPGHOME=~/.oldgnupg some-command . . . . .`</div><div> Or you can run `export GNUPGHOME=~/.oldgnupg` on a new terminal window,</div><div> and afterwards start the program that you wish to use.</div><div><br></div><div>I am not sure how well this would work for your case, but this is just another possible</div><div>solution. From my experience (and meditation) I have arrived in the conclusion that</div><div>usually it is better to keep only one secret key per context (or GNUPGHOME), and to</div><div>change the context whenever you need to use a different key.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
So, how could GnuPG make this decision more correctly and safely by<br>
default for normal users who want to transition in an orderly fashion to<br>
a new key? A couple ideas:<br>
<br>
* sign with the most recently-created key available. (does this mean<br>
we're looking at the age of the primary, or of the subkey?)<br>
<br>
* provide explicit prioritization mechanisms between these keys that<br>
are easy to use and easy to revert<br>
<br>
* allow locally disabling subkeys independently from primary keys, or<br>
even disabling key usage flags on the primary key.<br>
<br>
Any other suggestions? what have i missed? What should GnuPG do to<br>
handle this use case better?<br></blockquote><div><br></div><div>Maybe GnuPG should do something to improve the handling of GNUPGHOME,</div><div>if there is something to be improved about it.</div><div><br></div><div>Dashamir</div><div><br></div></div></div></div>