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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
