Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
W dniu pią, 06.07.2018 o godzinie 16∶21 +0200, użytkownik Marc Schiffbauer napisał: > * Kristian Fiskerstrand schrieb am 06.07.18 um 13:00 Uhr: > > On 07/05/2018 05:37 PM, Marc Schiffbauer wrote: > > > I have my primary key offline only, so renewing/editing it is a much > > > more time consuming matter than if I had my primary key always with me > > > which I consider a bad idea because you do not need to. > > > > But is it sufficiently time-consuming / difficult that it is a problem > > to do it once a year? What do you do when certifying/signing other's UIDs? > > Well, at least its annoying. For me personally it might even be that I > cannot commit to gentoo for some time when the key expired until I have > the chance to update my primary key again. > > And "some time" being somthing between 1 day and several weeks as I am > travelling a lot. > Again, we're talking about once a year. Nobody forces you to wait till it's almost expired to do it. You can practically renew it for 2 more years every time you have the opportunity. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
* Kristian Fiskerstrand schrieb am 06.07.18 um 13:00 Uhr: > On 07/05/2018 05:37 PM, Marc Schiffbauer wrote: > > I have my primary key offline only, so renewing/editing it is a much > > more time consuming matter than if I had my primary key always with me > > which I consider a bad idea because you do not need to. > > But is it sufficiently time-consuming / difficult that it is a problem > to do it once a year? What do you do when certifying/signing other's UIDs? Well, at least its annoying. For me personally it might even be that I cannot commit to gentoo for some time when the key expired until I have the chance to update my primary key again. And "some time" being somthing between 1 day and several weeks as I am travelling a lot. -- 0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07 6E9E CA3E 7BF6 7F97 9BE5 signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
On 06-07-2018 13:34:21 +0200, Ulrich Mueller wrote: > - Make creation of a revocation certificate (and storing it in a place > separate from the key) mandatory. What does this really achieve? Or require? Am I supposed to buy or hire a vault now? -- I'm assuming the word "safe" is missing from above sentence. Side observation: You can't check I have the revocation cert, let alone that you can check where it is stored, or if I lost it. Unless it is stored in a Gentoo owned vault or something, such that infra can invoke it on retirement scripts, this seems like unnecessary bureaucracy. Of course we want to encourage anyone to have a revocation cert, and to store it in a safe place somewhere. This is at best subject to means and opportunities of the person in question. In reality it is quite hard to store secrets securely, even more when they don't fit well in the human SSD. Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
On 07/06/2018 01:34 PM, Ulrich Mueller wrote: > Note that the revocation certificate is still listed under > recommendations only, so devs need not create one. Making this a > requirement would be a real improvement, IMHO. From a Gentoo perspective, we can "revoke" it by deleting it from LDAP and as such block access to push etc, so it actually is more important for other aspects of the ecosystem than for us. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
W dniu pią, 06.07.2018 o godzinie 13∶34 +0200, użytkownik Ulrich Mueller napisał: > > > > > > On Fri, 6 Jul 2018, Marc Schiffbauer wrote: > > * Michał Górny schrieb am 06.07.18 um 11:33 Uhr: > > > If you don't see it for 5 years, how can you be sure that it is > > > even still there? > > Are you serious? Who tells you that I do not check from time to > > time? > > I am sure there will always be some scenario which makes a key > > unacessible in some way. I do not disagree with that. Its a matter > > of propability. > > And for the worst case there is a revoke-Certificate which can be > > used. > > Note that the revocation certificate is still listed under > recommendations only, so devs need not create one. Making this a > requirement would be a real improvement, IMHO. How are you going to enforce it? I didn't make it a requirement because we simply can't verify it being met. > Instead, the GLEP draft is focusing on short expiration times. > It won't help much if your compromised key will expire within one > year, but you cannot revoke it. You're conflating two unrelated concepts. Expiration is not meant to replace revocation, or in any way amend it. Expiration is meant to cover the case of both the key and the revocation certificate being destroyed or otherwise becoming inaccessible. > > Suggestions: > - Change the minimum requirement for key expiry to at most 3 years > (which is what in version 1 is recommended). > - Recommend at most 15 months of key expiry, to be renewed at least > 2 weeks before the expiry date. > - Make creation of a revocation certificate (and storing it in a place > separate from the key) mandatory. > > Ulrich -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
> On Fri, 6 Jul 2018, Marc Schiffbauer wrote: > * Michał Górny schrieb am 06.07.18 um 11:33 Uhr: >> If you don't see it for 5 years, how can you be sure that it is >> even still there? > Are you serious? Who tells you that I do not check from time to > time? > I am sure there will always be some scenario which makes a key > unacessible in some way. I do not disagree with that. Its a matter > of propability. > And for the worst case there is a revoke-Certificate which can be > used. Note that the revocation certificate is still listed under recommendations only, so devs need not create one. Making this a requirement would be a real improvement, IMHO. Instead, the GLEP draft is focusing on short expiration times. It won't help much if your compromised key will expire within one year, but you cannot revoke it. Suggestions: - Change the minimum requirement for key expiry to at most 3 years (which is what in version 1 is recommended). - Recommend at most 15 months of key expiry, to be renewed at least 2 weeks before the expiry date. - Make creation of a revocation certificate (and storing it in a place separate from the key) mandatory. Ulrich pgp6gC2VcLz1v.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
On 07/05/2018 05:37 PM, Marc Schiffbauer wrote: > I have my primary key offline only, so renewing/editing it is a much > more time consuming matter than if I had my primary key always with me > which I consider a bad idea because you do not need to. But is it sufficiently time-consuming / difficult that it is a problem to do it once a year? What do you do when certifying/signing other's UIDs? -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
* Michał Górny schrieb am 06.07.18 um 11:33 Uhr: > W dniu pią, 06.07.2018 o godzinie 11∶08 +0200, użytkownik Marc > Schiffbauer napisał: > > * Michał Górny schrieb am 05.07.18 um 20:25 Uhr: > > > W dniu czw, 05.07.2018 o godzinie 17∶37 +0200, użytkownik Marc > > > Schiffbauer napisał: > > > > +1 for 5 years or at least 3. > > > > > > > > Having to renew/edit the key each year seems crazy to me. > > > > > > > > I have my primary key offline only, so renewing/editing it is a much > > > > more time consuming matter than if I had my primary key always with me > > > > which I consider a bad idea because you do not need to. > > > > > > > > > > ...and you consider it a good idea to keep the primary key untouched for > > > 5 years? You don't even know if the medium holding it still works. > > > > Yes. Backup media exists at a different place. > > If you don't see it for 5 years, how can you be sure that it is even > still there? Are you serious? Who tells you that I do not check from time to time? I am sure there will always be some scenario which makes a key unacessible in some way. I do not disagree with that. Its a matter of propability. And for the worst case there is a revoke-Certificate which can be used. -- 0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07 6E9E CA3E 7BF6 7F97 9BE5 signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
W dniu pią, 06.07.2018 o godzinie 11∶08 +0200, użytkownik Marc Schiffbauer napisał: > * Michał Górny schrieb am 05.07.18 um 20:25 Uhr: > > W dniu czw, 05.07.2018 o godzinie 17∶37 +0200, użytkownik Marc > > Schiffbauer napisał: > > > +1 for 5 years or at least 3. > > > > > > Having to renew/edit the key each year seems crazy to me. > > > > > > I have my primary key offline only, so renewing/editing it is a much > > > more time consuming matter than if I had my primary key always with me > > > which I consider a bad idea because you do not need to. > > > > > > > ...and you consider it a good idea to keep the primary key untouched for > > 5 years? You don't even know if the medium holding it still works. > > Yes. Backup media exists at a different place. If you don't see it for 5 years, how can you be sure that it is even still there? -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
* Michał Górny schrieb am 05.07.18 um 20:25 Uhr: > W dniu czw, 05.07.2018 o godzinie 17∶37 +0200, użytkownik Marc > Schiffbauer napisał: > > +1 for 5 years or at least 3. > > > > Having to renew/edit the key each year seems crazy to me. > > > > I have my primary key offline only, so renewing/editing it is a much > > more time consuming matter than if I had my primary key always with me > > which I consider a bad idea because you do not need to. > > > > ...and you consider it a good idea to keep the primary key untouched for > 5 years? You don't even know if the medium holding it still works. Yes. Backup media exists at a different place. -- 0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07 6E9E CA3E 7BF6 7F97 9BE5 signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
On Thu, Jul 5, 2018, at 08:36 CDT, Michał Górny wrote: > 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. Quoting the NIST standard in this regard is a bit silly. It recommends that the total "cryptoperiod" (this is the total timeinterval a single key should be actively used) of a private key for the purpose of signing shall be 1 - 3 years. (The publickey for verification is unspecified) If we would follow this to the letter, we would all have to rotate (not extend) our pgp keys after 3 years. Can we just do something sensible here? I.e. requiring a key expiry of 2 years on any key (primary and subkeys)? Two years is a reasonable timeframe. Everyone with an air-gapped primary key can afford the 30 minutes to update signatures *every other* year. Best, Matthias signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
W dniu czw, 05.07.2018 o godzinie 17∶37 +0200, użytkownik Marc Schiffbauer napisał: > * Matthias Maier schrieb am 05.07.18 um 15:51 Uhr: > > > > On Thu, Jul 5, 2018, at 08:36 CDT, Michał Górny wrote: > > > > > 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 > > > > Make it at most 2, 3, (or as it has been so far 5) years for both > > primary and subkeys. > > +1 for 5 years or at least 3. > > Having to renew/edit the key each year seems crazy to me. > > I have my primary key offline only, so renewing/editing it is a much > more time consuming matter than if I had my primary key always with me > which I consider a bad idea because you do not need to. > ...and you consider it a good idea to keep the primary key untouched for 5 years? You don't even know if the medium holding it still works. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
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. Thanks, William signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
* Matthias Maier schrieb am 05.07.18 um 15:51 Uhr: > > On Thu, Jul 5, 2018, at 08:36 CDT, Michał Górny wrote: > > > 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 > > Make it at most 2, 3, (or as it has been so far 5) years for both > primary and subkeys. +1 for 5 years or at least 3. Having to renew/edit the key each year seems crazy to me. I have my primary key offline only, so renewing/editing it is a much more time consuming matter than if I had my primary key always with me which I consider a bad idea because you do not need to. -Marc -- 0xCA3E7BF67F979BE5 - F7FB 78F7 7CC3 79F6 DF07 6E9E CA3E 7BF6 7F97 9BE5 signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
On Thu, Jul 5, 2018, at 08:36 CDT, Michał Górny wrote: > 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 Make it at most 2, 3, (or as it has been so far 5) years for both primary and subkeys. Best, Matthias signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
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
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
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. NAK on this. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org rsa6144/5C63F4E3F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
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. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
> 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? Ulrich pgpfeO7ifif_W.pgp Description: PGP signature
[gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory
Given that the key expiration can be updated in place, there is no reason to provide separate 'minimal' and 'recommended' values. --- glep-0063.rst | 19 ++- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/glep-0063.rst b/glep-0063.rst index e81c862..7455674 100644 --- a/glep-0063.rst +++ b/glep-0063.rst @@ -6,7 +6,7 @@ Author: Robin H. Johnson , Marissa Fischer Type: Standards Track Status: Final -Version: 1.1 +Version: 2 Created: 2013-02-18 Last-Modified: 2018-07-04 Post-History: 2013-11-10 @@ -27,6 +27,11 @@ OpenPGP key management policies for the Gentoo Linux distribution. Changes === +v2 + The recommended key expiration rules have been moved to the minimal + specification. Changing the expiration date of existing keys is possible + in-place so there is no need to provide for transitional 'minimum' value. + v1.1 The recommended RSA key size has been changed from 4096 bits to 2048 bits to match the GnuPG recommendations [#GNUPG-FAQ-11-4]_. @@ -71,7 +76,11 @@ not be used to commit. c. ECC, curve 25519 -3. Key expiry: 5 years maximum +3. Key expiration: + + a. Primary key: 3 years maximum + + b. Gentoo subkey: 1 year maximum 4. Upload your key to the SKS keyserver rotation before usage! @@ -128,11 +137,11 @@ their primary key). 2. Primary key and a dedicated signing subkey, both of type RSA, 2048 bits (OpenPGP v4 key format or later) -3. Key expiry: +3. Key expiration renewal: - a. Primary key: 3 years maximum, expiry date renewed annually. + a. Primary key: annual - b. Gentoo subkey: 1 year maximum, expiry date renewed every 6 months. + b. Gentoo subkey: every 6 months 4. Create a revocation certificate & store it hardcopy offsite securely (it's about ~300 bytes). -- 2.18.0
