Some questions about working with different versions of GnuPG and the fsfe's card on subkeys doc [UPDATED]]

stebe at mailbox.org stebe at mailbox.org
Fri Feb 12 16:44:31 CET 2016


(UPDATED]

> stebe at mailbox.org hat am 12. Februar 2016 um 11:43 geschrieben:
> 
> 
> Hi,
> 
> 
> just a few more questions on key generation and the fsfe doc (1) 
> 
> Following the indications in the referred document I have used a LIVE OS
> for all the steps indicated in it (up to now), and GnuPG version 2.1.9.
> 
> I understand that the sections starting with "Removing the master key
> from
> the keyring" up to "Remove backups from your machine" have to be
> performed
> on the machine/OS I actually use to work/communicate with gpg/Enigmail
> (GnuPG version 2.0.19).

Having thoroughly read the manpages of 2.1.9 (source machine) and 2.0.19
(target machine), respectively, and thought about the whole thing, I
deduce, for now, this result: (I thought I wouldn't have enough time to do
that as I posted my previous message...)


--> My new key:
1) --export --output [MyNewKeyID] to file [file]
2) --import key [MyNewKeyID] from file [file] --keep-ownertrust on target
machine -->that's the way to go....

--> copying private keys folder of 2.1.9 to version 2.0.19 should work (I
haven't created any new key with version 2.0.19 so there's nothing inside
yet), the "old" keys were (once) created using gpg 1.4.12) 

-->trustdb

trustdb on 2.1.x only contais the absolute/ultimative trust I set in my
own key (and its subkeys) --> --export-ownertrust (but isn't the
ownertrust of my new key, including subkeys, already being (implicitly)
exported using --export -output [MyNewKeyID] and thus updating
(implicitly) trustdb (target machine) on its import to version 2.0.x (-->
newly generated key has been, automatically, self-signed by version 2.1.x
and I self-signed my first uid with my second uid)
--> --keep-ownertrust as import-options parameter because on import
ownertrust values are stripped off of the new pub key

--> pubring.gpg of 2.0.19 (target machine) --> special topic: expiry of
disabled keys

(which started as a copy and paste of the 1.4.x's pubring, when I started
using 2.0.19) contains my disabled/revoked public keys (once created with
1.4.12) and other pub keys: so I can simply 
1) set an (very close, today's) expiry date to the disabled keys in order
to let them expire as soon as possible, then remove those keys from
pubring.gpg, or remove them right away, given the fact that I still have a
copy (of pubring and secring) in order to be able to put an expiry date
later) --> how important is it to let disabled keys expire (by activating
them for a "moment" in order to let them expire)? Would such proceeding be
a security risk, better leaving them disabled forever?

--> follow the remaining steps indicated in the referred FSFE's
card-howTo-doc (1)

Any objections, hints welcome.

Stebe

(1) https://wiki.fsfe.org/Card_howtos/Card_with_subkeys_using_backups



More information about the Gnupg-users mailing list