RFC on issue 2701, default expiration time for new keys
Justus Winter
justus at g10code.com
Fri Dec 9 14:55:54 CET 2016
Justus Winter <justus at g10code.com> writes:
> inspired by the talk on OpenKeychain UX decisions at the OpenPGP
> conference, I decided that it is a bad idea to let users create keys
> that don't expire (unless they want to hang themself with --expert).
Working on that I discovered that it is a bit more complicated (isn't it
always...?).
There are multiple ways to generate keys using GnuPG:
1) gpg --gen-key
2) gpg --full-gen-key
3) gpg --full-gen-key --expert
4) gpg --quick-gen-key
5) gpg --quick-addkey
1) is our simplified key generation dialog. I noticed that it creates
keys that do not expire at all, and I fixed that.
2) is the old key generation dialog. This asks for an expiration time,
and allows one to create keys that do not expire. Shall I change that?
3) this let's one shoot in the foot. No need to do anything here.
4) and 5) are part of the fairly recent --quick-* API that is (mostly)
intended for use with GPGME, but I guess this will see widespread use in
scripts too. 4) generates an identity key, 5) adds subkeys to an
existing key. Both allow one to specify an expiration time (optional,
or '-' to explicitly select the default, or the key words 'never' and
'none'). By default the keys generated using this way do not expire.
I'd like to change that as well.
Thoughts?
> This now begs the question what a good default expiration time is.
> Thoughts?
Based on the feedback I went with two years. Objections?
Justus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: </pipermail/attachments/20161209/31e9b3b4/attachment.sig>
More information about the Gnupg-devel
mailing list