GPG sub-keys

[Michael J Gruber]

Note there is a different though related problem/effect with sub-keys:

Adding stronger E and S subkeys is a typical "soft key upgrade path"
before one goes the full route of upgrading the primary (C) key and
losing all key signatures.

As someone mentioned, GnuPG will encrypt to the most recent supported E
subkey, which does make sense in the context above, and also in general:
if two sides of a channel support various schemes they agree on one and
use that (typically the best supported by both ends), not all of them.

If you re-init your pass store (say, to replace the e-mail address in
.gpg-id by a proper key-id) then pass checks the existing pass store for
the need to reencrypt:

- pass lists the subkey for all recipients specified in .gpg-id
  This gives all encryption subkeys, "!" appended makes no difference!

- For each stored file, pass lists the subkeys they were encrypted to.
  For GnuPG users, this will one in the scenario above.

- It notices the difference, says "reencrypting to {all the E subkeys}".
  This was quite a trigger for me - encrypting to the weaker/older E
  subkey?

- Then it reencrypts. For GnuPG users, this means reencrypting to the
  newest subkey only (possibly needlessly).

So, besides doing unnecessary reencryption, pass does not do what it
says it does.

I know I can expire the older E subkey (and still decrypt), but I'm
wondering whether it would make sense for pass to check the actual E
subkeys which the local gpg will use, i.e. instead of

gpg_keys="$($GPG --list-keys --with-colons
"${GPG_RECIPIENTS[@]}" | sed ...

use

gpg_keys="$(echo test | $GPG -e "${GPG_RECIPIENT_ARGS[@]}" | $GPG -v
--decrypt --list-only --keyid-format long | sed ...

(leaving out some of the standard options which pass uses).

As an intended "side-effect", this would not presume a specific gpg
behaviour but rather detect it automatically.

Cheers
Michael