Re: [gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update; full text
W dniu śro, 04.07.2018 o godzinie 23∶43 +0200, użytkownik Kristian Fiskerstrand napisał: > On 07/04/2018 11:28 PM, Michał Górny wrote: > > W dniu śro, 04.07.2018 o godzinie 23∶12 +0200, użytkownik Ulrich Mueller > > napisał: > > > > > > > > On Wed, 04 Jul 2018, Michał Górny wrote: > > > > > > > >b. Signing subkey: 1 year maximum > > > > 5. Key expiration date renewed at least 2 weeks before the previous > > > >expiration date. > > > > > > This is crappy as a scheme, since it will make it impossible to keep > > > the expiration date at a constant month and date. > > > > > > > Nobody forces you to prolong it for exactly the same amount, exactly two > > weeks before expiration. The only point made here is to give services > > time to sync rather than the common combo of renewing key once it > > already expired. > > > > Especially, if you follow the recommended scheme below you can easily > > get periodic expiration dates. > > > > As I understand ulm's concern, the issue is with the max 1 year in > combination with this, e.g it effectively prohibits extended a subkey > expiring 2018-12-31 to 2019-12-31 two weeks before, since that exceeds > one year maximum > We could say 'N year(s) + 2 weeks' but it would be kinda silly. Given that people are unhappy about one year anyway, let's defer this one for now. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update; full text
On 07/04/2018 11:43 PM, Kristian Fiskerstrand wrote: > On 07/04/2018 11:28 PM, Michał Górny wrote: >> W dniu śro, 04.07.2018 o godzinie 23∶12 +0200, użytkownik Ulrich Mueller >> napisał: On Wed, 04 Jul 2018, Michał Górny wrote: b. Signing subkey: 1 year maximum 5. Key expiration date renewed at least 2 weeks before the previous expiration date. >>> >>> This is crappy as a scheme, since it will make it impossible to keep >>> the expiration date at a constant month and date. >>> >> >> Nobody forces you to prolong it for exactly the same amount, exactly two >> weeks before expiration. The only point made here is to give services >> time to sync rather than the common combo of renewing key once it >> already expired. >> >> Especially, if you follow the recommended scheme below you can easily >> get periodic expiration dates. >> > > As I understand ulm's concern, the issue is with the max 1 year in > combination with this, e.g it effectively prohibits extended a subkey > expiring 2018-12-31 to 2019-12-31 two weeks before, since that exceeds > one year maximum > fwiw, this can be mitigated by allowing e.g 1.25 years / 15 months instead of one year. -- 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 00/11] Major GLEP 63 update; full text
> On Wed, 4 Jul 2018, Robin H Johnson wrote: >> >b. Signing subkey: 1 year maximum >> >> > 5. Key expiration date renewed at least 2 weeks before the >> >previous expiration date. > Only catch is that if I was doing it 2 weeks before, I'd want to > push it out another year or 6 months (depending on what), so it > would briefly be valid for 54 weeks. Exactly, and that would be forbidden by the new policy. Also I don't see why a shorter expiry of the subkey should be mandatory. Has the current policy (which permits same expiry of main key and subkey) caused any issues in the past? Ulrich pgpJfluJIM0_V.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update; full text
On 07/04/2018 11:28 PM, Michał Górny wrote: > W dniu śro, 04.07.2018 o godzinie 23∶12 +0200, użytkownik Ulrich Mueller > napisał: >>> On Wed, 04 Jul 2018, Michał Górny wrote: >>>b. Signing subkey: 1 year maximum >>> 5. Key expiration date renewed at least 2 weeks before the previous >>>expiration date. >> >> This is crappy as a scheme, since it will make it impossible to keep >> the expiration date at a constant month and date. >> > > Nobody forces you to prolong it for exactly the same amount, exactly two > weeks before expiration. The only point made here is to give services > time to sync rather than the common combo of renewing key once it > already expired. > > Especially, if you follow the recommended scheme below you can easily > get periodic expiration dates. > As I understand ulm's concern, the issue is with the max 1 year in combination with this, e.g it effectively prohibits extended a subkey expiring 2018-12-31 to 2019-12-31 two weeks before, since that exceeds one year maximum -- 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 00/11] Major GLEP 63 update; full text
On Wed, Jul 04, 2018 at 11:12:31PM +0200, Ulrich Mueller wrote: > > On Wed, 04 Jul 2018, Michał Górny wrote: > > >b. Signing subkey: 1 year maximum > > > 5. Key expiration date renewed at least 2 weeks before the previous > >expiration date. > This is crappy as a scheme, since it will make it impossible to keep > the expiration date at a constant month and date. Why will it make things difficult? In the expire prompt, you CAN specify an exact expire date or timestamp. Only catch is that if I was doing it 2 weeks before, I'd want to push it out another year or 6 months (depending on what), so it would briefly be valid for 54 weeks. -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update; full text
W dniu śro, 04.07.2018 o godzinie 23∶12 +0200, użytkownik Ulrich Mueller napisał: > > > > > > On Wed, 04 Jul 2018, Michał Górny wrote: > >b. Signing subkey: 1 year maximum > > 5. Key expiration date renewed at least 2 weeks before the previous > >expiration date. > > This is crappy as a scheme, since it will make it impossible to keep > the expiration date at a constant month and date. > Nobody forces you to prolong it for exactly the same amount, exactly two weeks before expiration. The only point made here is to give services time to sync rather than the common combo of renewing key once it already expired. Especially, if you follow the recommended scheme below you can easily get periodic expiration dates. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update; full text
> On Wed, 04 Jul 2018, Michał Górny wrote: >b. Signing subkey: 1 year maximum > 5. Key expiration date renewed at least 2 weeks before the previous >expiration date. This is crappy as a scheme, since it will make it impossible to keep the expiration date at a constant month and date. Ulrich pgpFK0sjc6DBj.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update; full text
Updated complete text after applying two more patches on k_f's request. --- GLEP: 63 Title: Gentoo OpenPGP policies Author: Robin H. Johnson , Andreas K. Hüttel , Marissa Fischer Type: Standards Track Status: Final Version: 2 Created: 2013-02-18 Last-Modified: 2018-07-04 Post-History: 2013-11-10 Content-Type: text/x-rst --- Credits === Many developers and external sources helped in this GLEP. Abstract This GLEP provides both a minimum requirement and a recommended set of 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. An additional rule requesting key renewal 2 weeks before expiration has been added. This is in order to give services and other developers time to refresh the key. The usage of DSA keys has been disallowed. 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]_. The larger recommendation was unjustified and resulted in people unnecessarily replacing their RSA-2048 keys. Minimal specification has been amended to allow for ECC keys. The option of using DSA subkey has been removed from recommendations. The section now specifies a single recommendation of using RSA. Motivation == Given the increasing use and importance of cryptographic protocols in internet transactions of any kind, unified requirements for OpenPGP keys used in Gentoo Linux development are sorely needed. This document provides both a set of bare minimum requirements and a set of best practice recommendations for the use of GnuPG (or other OpenPGP providers) by Gentoo Linux developers. It is intended to provide a basis for future improvements such as, e.g., consistent ebuild or package signing and verifying by end users. Specifications for OpenPGP keys === Bare minimum requirements - This section specifies obligatory requirements for all OpenPGP keys used to commit to Gentoo. Keys that do not conform to those requirements can not be used to commit. 1. SHA2-series output digest (SHA1 digests internally permitted), 256bit or more:: personal-digest-preferences SHA256 2. Signing subkey that is different from the primary key, and does not have any other capabilities enabled. 3. Primary key and the signing subkey are both of type EITHER: a. RSA, >=2048 bits (OpenPGP v4 key format or later only) b. ECC, curve 25519 4. Key expiration: a. Primary key: 3 years maximum b. Signing subkey: 1 year maximum 5. Key expiration date renewed at least 2 weeks before the previous expiration date. 6. Upload your key to the SKS keyserver rotation before usage! Recommendations --- This section specifies the best practices for Gentoo developers. The developers should follow those practices unless there is a strong technical reason not to (e.g. hardware limitations, necessity of replacing their primary key). 1. Copy ``/usr/share/gnupg/gpg-conf.skel`` to ``~/.gnupg/gpg.conf``, append the following block:: keyserver pool.sks-keyservers.net emit-version default-recipient-self # -- All of the below portion from the RiseUp.net OpenPGP best practices, and # -- many of them are also in the Debian GPG documentation. # when outputting certificates, view user IDs distinctly from keys: fixed-list-mode # long keyids are more collision-resistant than short keyids (it's trivial to make a key # with any desired short keyid) # NOTE: this breaks kmail gnupg support! keyid-format 0xlong # when multiple digests are supported by all recipients, choose the strongest one: personal-digest-preferences SHA512 SHA384 SHA256 SHA224 # preferences chosen for new keys should prioritize stronger algorithms: default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 BZIP2 ZLIB ZIP Uncompressed # If you use a graphical environment (and even if you don't) you should be using an agent: # (similar arguments as https://www.debian-administration.org/users/dkg/weblog/64) use-agent # You should always know at a glance which User IDs gpg thinks are legitimately bound to # the keys in your keyring: verify-options show-uid-validity list-options show-uid-validity # include an unambiguous indicator of which key made a signature: # (see http://thread.gmane.org/gmane.mail.notmuch.general/3721/focus=7234) # (and http://www.ietf.org/mail-archive/web/openpgp/current/msg00405.html) sig-notation issuer-...@notations.openpgp.fifthhorseman.net=%g # when making an OpenPGP cer
[gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update; full text
W dniu śro, 04.07.2018 o godzinie 12∶23 +0200, użytkownik Michał Górny napisał: > Hi, everyone. > > Following comments and other discussion, here's a bigger patch set > that updates GLEP 63 to v2. And of course I forgot to include the full text. Here it is: --- GLEP: 63 Title: Gentoo OpenPGP policies Author: Robin H. Johnson , Andreas K. Hüttel , Marissa Fischer Type: Standards Track Status: Final Version: 2 Created: 2013-02-18 Last-Modified: 2018-07-04 Post-History: 2013-11-10 Content-Type: text/x-rst --- Credits === Many developers and external sources helped in this GLEP. Abstract This GLEP provides both a minimum requirement and a recommended set of 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. An additional rule requesting key renewal 2 weeks before expiration has been added. This is in order to give services and other developers time to refresh the key. The usage of DSA keys has been disallowed. 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]_. The larger recommendation was unjustified and resulted in people unnecessarily replacing their RSA-2048 keys. Minimal specification has been amended to allow for ECC keys. The option of using DSA subkey has been removed from recommendations. The section now specifies a single recommendation of using RSA. Motivation == Given the increasing use and importance of cryptographic protocols in internet transactions of any kind, unified requirements for OpenPGP keys used in Gentoo Linux development are sorely needed. This document provides both a set of bare minimum requirements and a set of best practice recommendations for the use of GnuPG (or other OpenPGP providers) by Gentoo Linux developers. It is intended to provide a basis for future improvements such as, e.g., consistent ebuild or package signing and verifying by end users. Specifications for OpenPGP keys === Bare minimum requirements - This section specifies obligatory requirements for all OpenPGP keys used to commit to Gentoo. Keys that do not conform to those requirements can not be used to commit. 1. SHA2-series output digest (SHA1 digests internally permitted), 256bit or more:: personal-digest-preferences SHA256 2. Primary key and a dedicated signing subkey, both of EITHER: a. RSA, >=2048 bits (OpenPGP v4 key format or later only) b. ECC, curve 25519 3. Key expiration: a. Primary key: 3 years maximum b. Gentoo subkey: 1 year maximum 4. Key expiration date renewed at least 2 weeks before the previous expiration date. 5. Upload your key to the SKS keyserver rotation before usage! Recommendations --- This section specifies the best practices for Gentoo developers. The developers should follow those practices unless there is a strong technical reason not to (e.g. hardware limitations, necessity of replacing their primary key). 1. Copy ``/usr/share/gnupg/gpg-conf.skel`` to ``~/.gnupg/gpg.conf``, append the following block:: keyserver pool.sks-keyservers.net emit-version default-recipient-self # -- All of the below portion from the RiseUp.net OpenPGP best practices, and # -- many of them are also in the Debian GPG documentation. # when outputting certificates, view user IDs distinctly from keys: fixed-list-mode # long keyids are more collision-resistant than short keyids (it's trivial to make a key # with any desired short keyid) # NOTE: this breaks kmail gnupg support! keyid-format 0xlong # when multiple digests are supported by all recipients, choose the strongest one: personal-digest-preferences SHA512 SHA384 SHA256 SHA224 # preferences chosen for new keys should prioritize stronger algorithms: default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 BZIP2 ZLIB ZIP Uncompressed # If you use a graphical environment (and even if you don't) you should be using an agent: # (similar arguments as https://www.debian-administration.org/users/dkg/weblog/64) use-agent # You should always know at a glance which User IDs gpg thinks are legitimately bound to # the keys in your keyring: verify-options show-uid-validity list-options show-uid-validity # include an unambiguous indicator of which key made a signature: # (see http://thread.gmane.org/gmane.mail.notmuch.general/3721/focus=7234) # (and http://www.ietf.org/mail-archive/web/openpgp/current/msg00405.html) sig-notation issuer-...
[gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update
Hi, everyone. Following comments and other discussion, here's a bigger patch set that updates GLEP 63 to v2. It's divided into three parts: (1) editorial changes (do not change the spec but improve its wording) (2) backwards-compatible changes (existing keys still work) (3) backwards-incompatible changes (minimal spec updates) Each patch comes with a little rationale of its own, so I won't be repeating that here. Additionally, each patch is subject to separate discussion. Depending on the feedback, I might end up presenting those updates for Council approval in smaller parts. -- Best regards, Michał Górny Michał Górny (11): glep-0063: Use 'OpenPGP' as appropriate glep-0063: RSAv4 -> OpenPGP v4 key format glep-0063: Clarify dedicated signing subkey in minimal reqs glep-0063: Root key → primary key glep-0063: Explain minimal & recommended sections glep-0063: Change the recommended RSA key size to 2048 bits glep-0063: Allow ECC, curve 25519 keys glep-0063: Stop recommending DSA subkeys glep-0063: Make recommended expiration terms mandatory glep-0063: Require renewal 2 weeks before expiration glep-0063: Disallow using DSA keys glep-0063.rst | 98 +++ 1 file changed, 67 insertions(+), 31 deletions(-) -- 2.18.0
