Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory

[Michał Górny]

W dniu czw, 05.07.2018 o godzinie 13∶24 -0500, użytkownik William Hubbs
napisał:
> On Thu, Jul 05, 2018 at 03:36:09PM +0200, Michał Górny wrote:
> > 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
>
> Can you link the nist standard? I'm curious about it because their
> password standards are quite different.They no longer recommend forcing
> password changes unless there is a breach.
>

I'm afraid that's PDF.  Not sure if that will work for you:

https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-57pt1r4.pdf

It's section 5.3.6: Cryptoperiod Recommendations for Specific Key Types.

Quoting:

| 1. Private signature key:
| [...]
| b. Cryptoperiod: Given the use of approved algorithms and key sizes,
| and an expectation that the security of the key-storage and use
| environment will increase as the sensitivity and/or criticality
| of the processes for which the key provides integrity protection
| increases, a maximum cryptoperiod of about one to three years is
| recommended. The key shall be destroyed at the end of its
| cryptoperiod.


-- 
Best regards,
Michał Górny