Expiration of subkeys (was: Strange behaviour)

[Peter Lebbing]

On 12/12/16 21:09, Stephan Beck wrote:
> Well, the specific reason is that best practices exclude the usage of
> sub keys without any expiry.

There's nothing inherently wrong with non-expiring subkeys. Without
knowing the threat model, I don't see a reason to either start using
expiring subkeys *or* stop using them.

Coincidentally, expiration of subkeys by default was just discussed on
gnupg-devel; you might be interested in that little thread: [1]. If you
want to read the whole thread[2], not just this subthread, note that
Robert J. Hansen's contribution[3] went to gnupg-users instead of
gnupg-devel.

I recommend reading Robert's message anyway, since it also deals with
the whole concept of "best practices" in general. It's a good post and
apt here as well.

> See the FSFE's instructions in the known
> Offline master key and multiple subkeys on smart card guide (or similar,
> don't have the link right now).

When I did a quick look-see, I found that their recommended Card
HOWTO[4] actually creates a non-expiring key.

I don't know which intended public the FSFE's instructions have, or what
threat models they considered.

> The OP holds a main key without expiry date. In
> such a case, I'd set an expiry date on subkeys.

I'd set an expiry on the main key, or trust the OP to guard his
revocation certificate well (in the sense of not losing it).

HTH,

Peter.

[1] https://lists.gnupg.org/pipermail/gnupg-devel/2016-December/032328.html

[2] https://lists.gnupg.org/pipermail/gnupg-devel/2016-December/032298.html

[3] https://lists.gnupg.org/pipermail/gnupg-users/2016-December/057229.html

[4] http://wiki.fsfe.org/TechDocs/CardHowtos/CardWithSubkeysUsingBackups

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>