Rationale:
Users are clumsy, they will lose access to their secret key material, they will
lose the revocation certificate, and if the keys do not expire, there is no way
to get rid of them.
Plan:
Do not let users create keys without an expiration date unless they are in
--expert mode.
Usability considerations:
We should explain that it is possible to renew a key, and that it is not a huge
problem to forget to renew the key in time.
| rG GnuPG | |||
| rG8613230602ca gpg: Set default expiration date to 3 years. | |||
| rGbaa88832153d gpg: Set default expiration date to 3 years. | |||
| rKLEOPATRA Kleopatra | |||
| rKLEOPATRAd523249631de Change default expiry to three years in Kleo, too | |||
By renew you mean prolonging the expiration time?
To add this new default we should first add a --quick-set-expire command to make
it easier to change the expiration time. Or --quick-expire to match the name
used in --edit-key - I don't care. And of course gpgme needs a new API.
Would you mind to write to gnupg-devel and ask for comments on your proposal?
In particular on how long the default expiration time shall be. 12, 18, or 24
months?
--quick-keygen fixed in dd3dde07a9a46130ac01d849f8edf0566e44f11f.
The default expiration interval has been discussed on the mailing list. There
was a rough consensus on two years, which has been challenged by Neal who thinks
it is too short given the current state of the tools, but the ensuing discussion
did not revolve around the time span, so I'm keeping my two years for now. In
any case, it is easy to adjust.
I decided to not change the --full-key-gen, because a) the user asked for it, b)
changing that requires breaking up a large chunk of translated text, and I do
not want to do that right now (a release is imminent).
To align the default expiration time with the BSI approval and other related software we change this now to 3 years.