RSA pub-sec pri key pair + ELG enc + RSA sign subkeys + EDDSA/ECDH subkeys -> e-mail familiar RSA/ELG key recipient

[Fulano Diego Perez]

> On Fri, Jun 10, 2016, 3:58 AM Fulano Diego Perez 
> <<mailto:fulanoperez at cryptolab.net>fulanoperez at cryptolab.net> wrote:
> 
> will gnupg 2.1.x automatically select the senders' older _non
> expired_ RSA/ELG subkeys so the recipient can decrypt/verify
> signed/encrypted email ?
> 
> is the converse true for the sender for whatever software
> implementation they use (is this wishful thinking?) - in that their
> software will not fail after detecting newer incompatible subkeys,
> and then proceed to select the recipients' older but valid,
> compatible subkeys ?
> 
> in other words at this time can gnupg 2.1.x automatically,
> compatibly operate with both RSA and EDDSA/ECDH keys/subkeys ?
> 
> 
> This is exactly the situation I'm in with my public key,
> 0424DC19B678A1A9.
> 
> Here's what gpg2 -K shows:
> 
> sec   rsa4096/0424DC19B678A1A9 2014-10-08 [C] [expires: 2016-10-07] 
> uid                 [ultimate] Brian Minton 
> <<mailto:brian at minton.name>brian at minton.name> uid
> [ultimate] Brian Minton 
> <<mailto:bjmgeek at gmail.com>bjmgeek at gmail.com> uid
> [ultimate] Brian Minton 
> <<mailto:bminton at blinkenshell.org>bminton at blinkenshell.org> uid
> [ultimate] [jpeg image of size 5202] uid                 [ultimate]
> Brian Minton <<mailto:bminton at freeshell.de>bminton at freeshell.de> uid
> [ultimate] keybase.io/bjmgeek <http://keybase.io/bjmgeek>
> <bjmgeek at keybase.io <mailto:bjmgeek at keybase.io>> ssb
> nistp384/EA49CFDB55D113E9 2014-10-12 [E] [expires: 2016-10-11] ssb
> ed25519/37B9507ACFF2016E 2014-10-12 [S] [expires: 2016-10-11] ssb
> elg3200/28FA8B9659A70692 2016-03-07 [E] [expires: 2016-10-10] ssb
> elg2048/25353D56E26A744C 2014-10-09 [E] [expires: 2016-10-08] ssb
> elg2048/32483BAF5EA82613 2014-10-10 [E] [expires: 2016-10-09] ssb
> dsa2048/6B8EB3A065CFBAA9 2014-10-10 [S] [expires: 2016-10-09]
> 
> For encryption, people encrypting to you will use whatever key their 
> software can use. If the ECC key is newer, then senders that can use
> it will by default, while senders that can't will use your ELG key.
> So, keep both secret keys available and you'll be fine.  Note that I
> have a few extra ELG keys which I keep around just in case I need to
> decrypt a file that I encrypted with them.  There's nothing wrong
> with them, so I haven't revoked them.  However, gpg (and probably
> other PGP clients will use the newest usable key, so people
> encrypting to me with gpg2.1 will use EA49CFDB55D113E9 to encrypt,
> and people using gpg 2.0 and earlier will use 28FA8B9659A70692.
> 
> For signing, I like to put both key IDs (in my case, ed25519 and DSA)
> in my gnupg conf file, so signing automatically uses both keys. The
> trick is to use the key IDs of each subkey with an exclamation point
> so gnupg takes that specific key.

thanks so much for that tip
in the manual of course i missed it

> For instance, here are the relevant lines from my
> ~/.gnupg/gpg.conf-2 file (side note: if you use both gpg 1 and 2 you
> can use that kind of config file name to have different config files
> for each version):
> 
> *local-user 37B9507ACFF2016E! local-user 6B8EB3A065CFBAA9!*

good call

> 
> The nice thing about this setup is that I don't need to have any
> sender- or recipient-specific rules.

less headache than per-recipient i agree

trade-off for larger signature for me worth it