Renewing expiring key - done correctly?

[Hauke Laging]

Am Di 03.12.2013, 18:32:53 schrieb Eric Poellinger:

> 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

It would have been more helpful to see the exact steps for the operation that 
does NOT work...


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

Meaning what? As you are obviously doing something wrong this very general 
description isn't helpful at all. Maybe you just believe it's for the subkey.


> I am not 100% sure what you mean by 'marking' the key

Thus I gave the commands and (part of) the output:

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

After "key 1" the respective subkey is marked as "active" by the "*".


> 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.

A certificate update takes seconds only (and you can run it when the main 
process has just finished). Or just a share of a second if you suppress the 
trustdb calculations (or the keyring is small).


> 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?

You can make the changes to the certificate on another system so that yours 
running this process doesn't have any downtime but just the one second import 
of the new certificate.


> What if the trading partner
> requires lots of paperwork (e.g. banks) like faxes on top of emails?!

I do not see how this is related to the technical questions we can answer. We 
know nothing about this paperwork. I am not even sure what your question is. 
If key updates are difficult then do not update the keys (more often than 
really necessary). This leads to the next recommendation: secure the keys. Use 
them in a very limited environment only.

It may make sense to create separate keys for each business contact (or at 
least one for each "paperwork business contact") in order to minimize the 
effects of activities not related to this contact to the key for this contact.

Another idea: It may help to have a separate certification key (like your own 
CA) which is used in a "very secure" environment only. Your contacts can make 
a trust signature (tsign) for this key so that new (main)keys with email 
addresses in your domain become valid automatically. But whether this causes 
more or less paperwork depends on your contact's policy.


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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 572 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20131204/39a18817/attachment.sig>