On Tue 2018-04-17 09:52:56 +0800, gustavo panizzo wrote: > I would advise you against generating new subkeys, after some years your > public key will be a mess (like mine, 0x44BB1BA79F6C6333), as you cannot > never remove expired/revoked keys from the public part.
What's the problem here? is it the size of the OpenPGP certificate? The way it's presented on the keyservers' webinterface? or are people actually encrypting to your expired subkeys? aiui, most OpenPGP clients are capable of simply ignoring expired/extraneous subkeys; if they're not doing that right, we need some more active bug reporting :) I've started here, encouraging some standard implementations to drop unusable subkeys from "clean" OpenPGP certificate export: https://dev.gnupg.org/T3622 I welcome other bug reports that encourage this kind of good data management. > If you are talking about private-company wide keys, it may make sense > but for your personal life-long key I don't think is worth it Should we be encouraging "life-long" keys? I know that primary key migration is a pain, but at some point it makes sense to switch algorithms, even if your key material was never compromised (compromised primary key material would warrant an earlier rotation of course) But let's say that you use your key for a career-spanning three decades, and you rotate three subkeys (E,S,A) every year, and you use 4Kb RSA keys. By the end of this time, the assembled historic subkeys, binding signatures, and cross-certifications are still less than 128KB. Is this really too large to accept? (and of course, you can still distribute the more compact, pruned certificate that contains only the latest subkeys) so, I don't think your public key is a mess! :) --dkg
