Renewing expiring key - done correctly?

[Eric Poellinger]

First, thank you for taking the time to reply!

Regarding the steps I took to expire the keys (4A4DBDC7 is the primary key, 0C0305EC is the sub)
1. gpg --edit-key 4A4DBDC7 
1a. expire...2y
1b. enter passphrase
1c. quit and save

2. same as #1, but for the sub-key

I am not 100% sure what you mean by 'marking' the key - and I assume the 'quit and save' is saving the key ring



Regarding the "renewal" best practice I am thinking about scenarios where you have automated file transfers and how to minimize the coordination effort so as not to disrupt and data flows.  For example, if process runs every 10 minutes to encrypt, sign and send a file, do you just have to accept there is some 'downtime' while you update the key, send it to the trading partner and have them import it?  What if the trading partner requires lots of paperwork (e.g. banks) like faxes on top of emails?!

Thanks again for your support.



On Tuesday, December 3, 2013 5:44 PM, Hauke Laging <mailinglisten at hauke-laging.de> wrote:
 
Am Di 03.12.2013, 08:22:28 schrieb Eric Poellinger:

> PRIMARY QUESTIONS - I am uncertain about the sub-key.  When I attempt to
> 'expire' it the date does not seem to change.

What exactly did you do? Did you mark the subkey before and did you save the 
changes to the keyring after the expire command?

gpg> key 1

pub  3072R/0x711D8152  created: 2013-11-27  expires: 2014-11-27  usage: SCE 
                       trust: ultimate      validity: ultimate
sub* 2048R/0x48C7F0CD  created: 2013-11-27  expires: 2015-12-03  usage: S  

[...]

gpg> save


> Maybe you cannot expire a sub-key?

You can.



> SECONDARY QUESTION - is there documentation regarding 'best practices' on
> managing expiring keys and renewing via sub-keys --- my theory is that
> doing it this way minimizes the coordination necessary but I am not
> understanding how it works if you have multiple trading partners to
> coordinate with.

Expiration serves two purposes:
1) Passively revoke a key if you have lost access to the secret mainkey (i.e. 
to the key itself or to its passphrase).
2) Force your communication partners (people are lazy) to update your 
certificate from time to time (requires some understanding on their side).

The length of the validity period is a compromise between higher "security" 
and less inconvenience (your own, too).

I am not sure whether I understand correctly what you mean by "renewing". You 
can prolong the validity of subkeys and you can replace subkeys. It's not a 
big difference for your communication partners. Replacing subkeys for security 
reasons makes real sense only if you use a secure offline mainkey.

Usually you upload your certificate (public key) to a key server (or more) 
from where everyone can get updates of your certificate.


Hauke
-- 
Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/
http://userbase.kde.org/Concepts/OpenPGP_Help_Spread
OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20131203/ebcdc0b7/attachment-0001.html>