W dniu śro, 04.07.2018 o godzinie 18∶48 -0400, użytkownik Joshua Kinard napisał: > On 7/4/2018 5:24 PM, Michał Górny wrote: > > W dniu śro, 04.07.2018 o godzinie 23∶05 +0200, użytkownik Ulrich Mueller > > napisał: > > > > > > > > On Wed, 4 Jul 2018, Michał Górny wrote: > > > > > > > > -3. Key expiry: 5 years maximum > > > > +3. Key expiration: > > > > + > > > > + a. Primary key: 3 years maximum > > > > + > > > > + b. Gentoo subkey: 1 year maximum > > > > > > What problem are you trying to solve here? > > > > > > > The problem of having unjustified double standards. > > IMHO, one year for a signing subkey is too short. I see no problem with three > years like the primary key. Especially since people will typically just > change > the expiration and advance it the minimum number of years, lather, rinse, and > repeat. It's a solution looking for a problem. >
I don't really know the original rationale for this. The NIST standard says 1-3 years. If I were to guess, I'd say 1 year was chosen for subkey because subkey expiring is a 'smaller' issue than the whole key expiring, i.e. other users see the primary key as being still valid. I suppose the advantage of having disjoint expiration times is that if you forget about it, you'd learn the hard way that you need to renew it before the primary key expired. That said, I'm open to using a different recommendation, e.g. 2 years as in riseup [1]. I suppose having the same time for both primary key and subkeys would make the spec simpler, and many developers are mistaking expiration times (as specified now) anyway. [1]:https://riseup.net/en/security/message-security/openpgp/best-practices#use-an-expiration-date-less-than-two-years -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
