[gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update

[gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update

[Michał Górny]

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

[gentoo-dev] [PATCH v2 01/11] glep-0063: Use 'OpenPGP' as appropriate

[Michał Górny]

Replace many of the incorrect uses of GPG/GnuPG [key] with OpenPGP.
G[nu]PG has been left where the text clearly refers to the specific
implementation of OpenPGP rather than the standard itself.
---
 glep-0063.rst | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/glep-0063.rst b/glep-0063.rst
index c59d545..dd61ecc 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -1,6 +1,6 @@
 ---
 GLEP: 63
-Title: Gentoo GPG key policies
+Title: Gentoo OpenPGP policies
 Author: Robin H. Johnson <robbat2@gentoo.org>,
         Andreas K. Hüttel <dilfridge@gentoo.org>,
         Marissa Fischer <blogtodiffer@gmail.com>
@@ -8,7 +8,7 @@ Type: Standards Track
 Status: Final
 Version: 1
 Created: 2013-02-18
-Last-Modified: 2015-08-25
+Last-Modified: 2018-07-02
 Post-History: 2013-11-10
 Content-Type: text/x-rst
 ---
@@ -21,22 +21,22 @@ Many developers and external sources helped in this GLEP.
 Abstract
 ========
 
-This GLEP provides both a minimum requirement and a recommended set of GPG
-key management policies for the Gentoo Linux distribution.
+This GLEP provides both a minimum requirement and a recommended set of
+OpenPGP key management policies for the Gentoo Linux distribution.
 
 Motivation
 ==========
 
 Given the increasing use and importance of cryptographic protocols in internet
-transactions of any kind, unified requirements for GnuPG keys used in Gentoo
+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 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.
+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 GnuPG keys
-=============================
+Specifications for OpenPGP keys
+===============================
 
 Bare minimum requirements
 -------------------------
@@ -125,7 +125,7 @@ Recommendations
 Gentoo LDAP
 ===========
 
-All Gentoo developers must list the complete GPG fingerprint for their root
+All Gentoo developers must list the complete fingerprint for their root
 keys in the "``gpgfingerprint``" LDAP field. It must be exactly 40 hex digits,
 uppercase, with optional spaces every 8 hex digits. Regular expression for
 validation::
-- 
2.18.0

[gentoo-dev] [PATCH v2 02/11] glep-0063: RSAv4 -> OpenPGP v4 key format

[Michał Górny]

Replace the 'RSAv4' with 'OpenPGP v4 key format'.  The RSA algorithm
does not really have versions, and the author most likely meant the v4
of OpenPGP key format as outlined in RFC 4880, section 12.1.

This was figured out and explained to me by Kristian Fiskerstrand.
---
 glep-0063.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/glep-0063.rst b/glep-0063.rst
index dd61ecc..8e4f0d5 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -49,7 +49,7 @@ Bare minimum requirements
 
    a. DSA, 2048-bit
 
-   b. RSA, >=2048 bits, RSAv4 or later only
+   b. RSA, >=2048 bits (OpenPGP v4 key format or later only)
 
 3. Key expiry: 5 years maximum
 
@@ -101,7 +101,7 @@ Recommendations
        # when making an OpenPGP certification, use a stronger digest than the default SHA1:
        cert-digest-algo SHA256
 
-2. Root key type RSA, 4096 bits, RSAv4 or later
+2. Root key type RSA, 4096 bits (OpenPGP v4 key format or later)
 
    This may require creating an entirely new key.
 
-- 
2.18.0

[gentoo-dev] [PATCH v2 03/11] glep-0063: Clarify dedicated signing subkey in minimal reqs

[Michał Górny]

Reword the minimal requirements to clearly indicate that a dedicated
signing subkey is required.  The current wording may make it unclear
whether the 'root key' and 'signing subkey' can be the same key.
---
 glep-0063.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/glep-0063.rst b/glep-0063.rst
index 8e4f0d5..0082edd 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -45,7 +45,7 @@ Bare minimum requirements
 
        personal-digest-preferences SHA256
 
-2. Root key and signing subkey of EITHER:
+2. Root key and a dedicated signing subkey, both of EITHER:
 
    a. DSA, 2048-bit
 
-- 
2.18.0

Re: [gentoo-dev] [PATCH v2 03/11] glep-0063: Clarify dedicated signing subkey in minimal reqs

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 404 bytes --]

On 07/04/2018 12:23 PM, Michał Górny wrote:
> -2. Root key and signing subkey of EITHER:
> +2. Root key and a dedicated signing subkey, both of EITHER:

"dedicated" here might be misread to be gentoo-specific, which doesn't
really make much sense.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] [PATCH v2 03/11] glep-0063: Clarify dedicated signing subkey in minimal reqs

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 552 bytes --]

W dniu śro, 04.07.2018 o godzinie 12∶35 +0200, użytkownik Kristian
Fiskerstrand napisał:
> On 07/04/2018 12:23 PM, Michał Górny wrote:
> > -2. Root key and signing subkey of EITHER:
> > +2. Root key and a dedicated signing subkey, both of EITHER:
> 
> "dedicated" here might be misread to be gentoo-specific, which doesn't
> really make much sense.

What alternative do you suggest?  We really want to make clear that we
require a separate subkey, and that subkey is not marked for encryption.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-dev] [PATCH v2 03/11] glep-0063: Clarify dedicated signing subkey in minimal reqs

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 876 bytes --]

On 07/04/2018 12:54 PM, Michał Górny wrote:
> W dniu śro, 04.07.2018 o godzinie 12∶35 +0200, użytkownik Kristian
> Fiskerstrand napisał:
>> On 07/04/2018 12:23 PM, Michał Górny wrote:
>>> -2. Root key and signing subkey of EITHER:
>>> +2. Root key and a dedicated signing subkey, both of EITHER:
>>
>> "dedicated" here might be misread to be gentoo-specific, which doesn't
>> really make much sense.
> 
> What alternative do you suggest?  We really want to make clear that we
> require a separate subkey, and that subkey is not marked for encryption.
> 

"signing subkey" already implies as much though, but maybe write it out
more "Both the primary key and the signing subkey needs to be of EITHER;"

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] [PATCH v2 03/11] glep-0063: Clarify dedicated signing subkey in minimal reqs

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 989 bytes --]

W dniu śro, 04.07.2018 o godzinie 12∶58 +0200, użytkownik Kristian
Fiskerstrand napisał:
> On 07/04/2018 12:54 PM, Michał Górny wrote:
> > W dniu śro, 04.07.2018 o godzinie 12∶35 +0200, użytkownik Kristian
> > Fiskerstrand napisał:
> > > On 07/04/2018 12:23 PM, Michał Górny wrote:
> > > > -2. Root key and signing subkey of EITHER:
> > > > +2. Root key and a dedicated signing subkey, both of EITHER:
> > > 
> > > "dedicated" here might be misread to be gentoo-specific, which doesn't
> > > really make much sense.
> > 
> > What alternative do you suggest?  We really want to make clear that we
> > require a separate subkey, and that subkey is not marked for encryption.
> > 
> 
> "signing subkey" already implies as much though, but maybe write it out
> more "Both the primary key and the signing subkey needs to be of EITHER;"
> 

Or maybe even make a separate point about having a separate signing
subkey?

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-dev] [PATCH v2 03/11] glep-0063: Clarify dedicated signing subkey in minimal reqs

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 339 bytes --]

On 07/04/2018 12:59 PM, Michał Górny wrote:

> 
> Or maybe even make a separate point about having a separate signing
> subkey?
> 

Right, that is likely also easier to understand.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] [PATCH v2 03/11] glep-0063: Clarify dedicated signing subkey in minimal reqs

[Matthew Thode]

[-- Attachment #1: Type: text/plain, Size: 887 bytes --]

On 18-07-04 12:54:50, Michał Górny wrote:
> W dniu śro, 04.07.2018 o godzinie 12∶35 +0200, użytkownik Kristian
> Fiskerstrand napisał:
> > On 07/04/2018 12:23 PM, Michał Górny wrote:
> > > -2. Root key and signing subkey of EITHER:
> > > +2. Root key and a dedicated signing subkey, both of EITHER:
> > 
> > "dedicated" here might be misread to be gentoo-specific, which doesn't
> > really make much sense.
> 
> What alternative do you suggest?  We really want to make clear that we
> require a separate subkey, and that subkey is not marked for encryption.
> 

I'd suggest something along the lines of 'subkey with signing only
capabilitiyies' or 'signing only subkey'.  I state this because you are
able to have a combined SE subkey which would match the language of
dedicated or simply only saying 'signing subkey'.

-- 
Matthew Thode (prometheanfire)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] [PATCH v2 03/11] glep-0063: Clarify dedicated signing subkey in minimal reqs

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 541 bytes --]

W dniu śro, 04.07.2018 o godzinie 12∶35 +0200, użytkownik Kristian
Fiskerstrand napisał:
> On 07/04/2018 12:23 PM, Michał Górny wrote:
> > -2. Root key and signing subkey of EITHER:
> > +2. Root key and a dedicated signing subkey, both of EITHER:
> 
> "dedicated" here might be misread to be gentoo-specific, which doesn't
> really make much sense.
> 

Hmm, actually the recommended spec already talks of 'dedicated', so I'll
change it as an additional commit rather than in place.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

[gentoo-dev] [PATCH v2 04/11] glep-0063: Root key → primary key

[Michał Górny]

Replace the custom term 'root key' with much more common 'primary key'.
This is also the term used in GnuPG output.
---
 glep-0063.rst | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/glep-0063.rst b/glep-0063.rst
index 0082edd..2a5e02f 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -8,7 +8,7 @@ Type: Standards Track
 Status: Final
 Version: 1
 Created: 2013-02-18
-Last-Modified: 2018-07-02
+Last-Modified: 2018-07-04
 Post-History: 2013-11-10
 Content-Type: text/x-rst
 ---
@@ -45,7 +45,7 @@ Bare minimum requirements
 
        personal-digest-preferences SHA256
 
-2. Root key and a dedicated signing subkey, both of EITHER:
+2. Primary key and a dedicated signing subkey, both of EITHER:
 
    a. DSA, 2048-bit
 
@@ -101,7 +101,7 @@ Recommendations
        # when making an OpenPGP certification, use a stronger digest than the default SHA1:
        cert-digest-algo SHA256
 
-2. Root key type RSA, 4096 bits (OpenPGP v4 key format or later)
+2. Primary key type RSA, 4096 bits (OpenPGP v4 key format or later)
 
    This may require creating an entirely new key.
 
@@ -113,7 +113,7 @@ Recommendations
 
 4. Key expiry:
 
-   a. Root key: 3 years maximum, expiry date renewed annually.
+   a. Primary key: 3 years maximum, expiry date renewed annually.
 
    b. Gentoo subkey: 1 year maximum, expiry date renewed every 6 months.
 
@@ -125,7 +125,7 @@ Recommendations
 Gentoo LDAP
 ===========
 
-All Gentoo developers must list the complete fingerprint for their root
+All Gentoo developers must list the complete fingerprint for their primary
 keys in the "``gpgfingerprint``" LDAP field. It must be exactly 40 hex digits,
 uppercase, with optional spaces every 8 hex digits. Regular expression for
 validation::
-- 
2.18.0

[gentoo-dev] [PATCH v2 05/11] glep-0063: Explain minimal & recommended sections

[Michał Górny]

---
 glep-0063.rst | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/glep-0063.rst b/glep-0063.rst
index 2a5e02f..4c22fbe 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -40,6 +40,10 @@ 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::
 
@@ -57,6 +61,10 @@ Bare minimum requirements
 
 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::
-- 
2.18.0

[gentoo-dev] [PATCH v2 06/11] glep-0063: Change the recommended RSA key size to 2048 bits

[Michał Górny]

Change the recommended key size recommendation for RSA from 4096 bits
to 2048 bits.  Use of larger keys is unjustified due to negligible gain
in security, and recommending RSA-4096 unnecessarily resulted
in developers replacing their RSA-2048 keys for no good reason.
---
 glep-0063.rst | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/glep-0063.rst b/glep-0063.rst
index 4c22fbe..6dc4ce5 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -6,7 +6,7 @@ Author: Robin H. Johnson <robbat2@gentoo.org>,
         Marissa Fischer <blogtodiffer@gmail.com>
 Type: Standards Track
 Status: Final
-Version: 1
+Version: 1.1
 Created: 2013-02-18
 Last-Modified: 2018-07-04
 Post-History: 2013-11-10
@@ -24,6 +24,15 @@ Abstract
 This GLEP provides both a minimum requirement and a recommended set of
 OpenPGP key management policies for the Gentoo Linux distribution.
 
+Changes
+=======
+
+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.
+
 Motivation
 ==========
 
@@ -109,7 +118,7 @@ their primary key).
        # when making an OpenPGP certification, use a stronger digest than the default SHA1:
        cert-digest-algo SHA256
 
-2. Primary key type RSA, 4096 bits (OpenPGP v4 key format or later)
+2. Primary key type RSA, 2048 bits (OpenPGP v4 key format or later)
 
    This may require creating an entirely new key.
 
@@ -117,7 +126,7 @@ their primary key).
 
    a. DSA 2048 bits exactly.
 
-   b. RSA 4096 bits exactly.
+   b. RSA 2048 bits exactly.
 
 4. Key expiry:
 
@@ -170,6 +179,9 @@ Much of the above was driven by the following:
 References
 ==========
 
+.. [#GNUPG-FAQ-11-4] GnuPG FAQ: Why doesn’t GnuPG default to using RSA-4096?
+   (https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096)
+
 .. [#DEBIANGPG] Debian GPG documentation
    (https://wiki.debian.org/Keysigning)
 
-- 
2.18.0

[gentoo-dev] [PATCH v2 07/11] glep-0063: Allow ECC, curve 25519 keys

[Michał Górny]

Optionally allow using ECC, curve 25519 keys.  We already have
developers using those keys, and given that they are supported
by GnuPG 2.2, there's probably no reason to ban them.  However, they're
not recommended due to interoperability issues.
---
 glep-0063.rst | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/glep-0063.rst b/glep-0063.rst
index 6dc4ce5..ab7cb79 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -33,6 +33,8 @@ v1.1
   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.
+
 Motivation
 ==========
 
@@ -64,6 +66,8 @@ not be used to commit.
 
    b. RSA, >=2048 bits (OpenPGP v4 key format or later only)
 
+   c. ECC, curve 25519
+
 3. Key expiry: 5 years maximum
 
 4. Upload your key to the SKS keyserver rotation before usage!
-- 
2.18.0

Re: [gentoo-dev] [PATCH v2 07/11] glep-0063: Allow ECC, curve 25519 keys

[Joshua Kinard]

On 7/4/2018 6:23 AM, Michał Górny wrote:
> Optionally allow using ECC, curve 25519 keys.  We already have
> developers using those keys, and given that they are supported
> by GnuPG 2.2, there's probably no reason to ban them.  However, they're
> not recommended due to interoperability issues.
> ---
>  glep-0063.rst | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/glep-0063.rst b/glep-0063.rst
> index 6dc4ce5..ab7cb79 100644
> --- a/glep-0063.rst
> +++ b/glep-0063.rst
> @@ -33,6 +33,8 @@ v1.1
>    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.
> +
>  Motivation
>  ==========
>  
> @@ -64,6 +66,8 @@ not be used to commit.
>  
>     b. RSA, >=2048 bits (OpenPGP v4 key format or later only)
>  
> +   c. ECC, curve 25519
> +
>  3. Key expiry: 5 years maximum
>  
>  4. Upload your key to the SKS keyserver rotation before usage!
> 

Add a minimum key size here for ECC.  They have different bit sizes than
classic DSA/RSA keys.  A quick read indicates that a 224-bit ECC key is roughly
equivalent to a 112-bit symmetric key, which is what a 2048-bit RSA key is
equivalent to, so the logical minimum for ECC looks like 'nistp256'.  The
maximum is 521-bits on ECC (nistp521).

Also move the mention of Ed25519 keys to their own bullet and clarify that they
don't allow for a key length, as I think that's hardcoded in some capacity.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@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 07/11] glep-0063: Allow ECC, curve 25519 keys

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 1996 bytes --]

On 07/05/2018 01:07 AM, Joshua Kinard wrote:
>> @@ -64,6 +66,8 @@ not be used to commit.
>>  
>>     b. RSA, >=2048 bits (OpenPGP v4 key format or later only)
>>  
>> +   c. ECC, curve 25519
>> +
>>  3. Key expiry: 5 years maximum
>>  
>>  4. Upload your key to the SKS keyserver rotation before usage!
>>
> Add a minimum key size here for ECC.  They have different bit sizes than
> classic DSA/RSA keys.  A quick read indicates that a 224-bit ECC key is roughly
> equivalent to a 112-bit symmetric key, which is what a 2048-bit RSA key is
> equivalent to, so the logical minimum for ECC looks like 'nistp256'.  The
> maximum is 521-bits on ECC (nistp521).
> 
> Also move the mention of Ed25519 keys to their own bullet and clarify that they
> don't allow for a key length, as I think that's hardcoded in some capacity.

following the comma-style of the rest of the document, the ECC part
should likely be read as curve25519 being the only acceptable curve,
which is 256 bits (roughtly 128 bit shannon entropy equivalent)

that said, I'm not aware of any curves defined with a lower security
margin than this for OpenPGP in general. The known curves in the
ecosystem are

let oid_to_psize oid =
   let psize = match oid with
     | "\x2b\x81\x04\x00\x23" -> 521         		(* nistp521 *)
     | "\x2b\x81\x04\x00\x22" -> 384         		(* nistp384 *)
     | "\x2a\x86\x48\xce\x3d\x03\x01\x07" -> 256   	(* nistp256 *)
     | "\x2b\x24\x03\x03\x02\x08\x01\x01\x07" -> 256 	(* brainpoolP256r1 *)
     | "\x2b\x24\x03\x03\x02\x08\x01\x01\x0b" -> 384 	(* brainpoolP384r1 *)
     | "\x2b\x24\x03\x03\x02\x08\x01\x01\x0d" -> 512 	(* brainpoolP512r1 *)
     | "\x2b\x81\x04\x00\x0a" -> 256         		(* secp256k1 *)
     | "\x2b\x06\x01\x04\x01\xda\x47\x0f\x01" -> 256	(* Ed25519 *)
     | _ -> failwith "Unknown OID"

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] [PATCH v2 07/11] glep-0063: Allow ECC, curve 25519 keys

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 433 bytes --]

On 07/05/2018 01:22 AM, Kristian Fiskerstrand wrote:
> that said, I'm not aware of any curves defined with a lower security
> margin than this for OpenPGP in general. The known curves in the
> ecosystem are

known in the ecosystem being the union of rfc4880bis draft and rfc6637

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] [PATCH v2 07/11] glep-0063: Allow ECC, curve 25519 keys

[Joshua Kinard]

On 7/4/2018 7:22 PM, Kristian Fiskerstrand wrote:
> On 07/05/2018 01:07 AM, Joshua Kinard wrote:
>>> @@ -64,6 +66,8 @@ not be used to commit.
>>>  
>>>     b. RSA, >=2048 bits (OpenPGP v4 key format or later only)
>>>  
>>> +   c. ECC, curve 25519
>>> +
>>>  3. Key expiry: 5 years maximum
>>>  
>>>  4. Upload your key to the SKS keyserver rotation before usage!
>>>
>> Add a minimum key size here for ECC.  They have different bit sizes than
>> classic DSA/RSA keys.  A quick read indicates that a 224-bit ECC key is roughly
>> equivalent to a 112-bit symmetric key, which is what a 2048-bit RSA key is
>> equivalent to, so the logical minimum for ECC looks like 'nistp256'.  The
>> maximum is 521-bits on ECC (nistp521).
>>
>> Also move the mention of Ed25519 keys to their own bullet and clarify that they
>> don't allow for a key length, as I think that's hardcoded in some capacity.
> 
> following the comma-style of the rest of the document, the ECC part
> should likely be read as curve25519 being the only acceptable curve,
> which is 256 bits (roughtly 128 bit shannon entropy equivalent)
> 
> that said, I'm not aware of any curves defined with a lower security
> margin than this for OpenPGP in general. The known curves in the
> ecosystem are
> 
> let oid_to_psize oid =
>    let psize = match oid with
>      | "\x2b\x81\x04\x00\x23" -> 521         		(* nistp521 *)
>      | "\x2b\x81\x04\x00\x22" -> 384         		(* nistp384 *)
>      | "\x2a\x86\x48\xce\x3d\x03\x01\x07" -> 256   	(* nistp256 *)
>      | "\x2b\x24\x03\x03\x02\x08\x01\x01\x07" -> 256 	(* brainpoolP256r1 *)
>      | "\x2b\x24\x03\x03\x02\x08\x01\x01\x0b" -> 384 	(* brainpoolP384r1 *)
>      | "\x2b\x24\x03\x03\x02\x08\x01\x01\x0d" -> 512 	(* brainpoolP512r1 *)
>      | "\x2b\x81\x04\x00\x0a" -> 256         		(* secp256k1 *)
>      | "\x2b\x06\x01\x04\x01\xda\x47\x0f\x01" -> 256	(* Ed25519 *)
>      | _ -> failwith "Unknown OID"
> 

By "only acceptable curve", do you mean we shouldn't allow the nistp* key
types, only Ed25519?

-- 
Joshua Kinard
Gentoo/MIPS
kumba@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 07/11] glep-0063: Allow ECC, curve 25519 keys

[R0b0t1]

On Wed, Jul 4, 2018 at 7:18 PM, Joshua Kinard <kumba@gentoo.org> wrote:
> On 7/4/2018 7:22 PM, Kristian Fiskerstrand wrote:
>> On 07/05/2018 01:07 AM, Joshua Kinard wrote:
>>>> @@ -64,6 +66,8 @@ not be used to commit.
>>>>
>>>>     b. RSA, >=2048 bits (OpenPGP v4 key format or later only)
>>>>
>>>> +   c. ECC, curve 25519
>>>> +
>>>>  3. Key expiry: 5 years maximum
>>>>
>>>>  4. Upload your key to the SKS keyserver rotation before usage!
>>>>
>>> Add a minimum key size here for ECC.  They have different bit sizes than
>>> classic DSA/RSA keys.  A quick read indicates that a 224-bit ECC key is roughly
>>> equivalent to a 112-bit symmetric key, which is what a 2048-bit RSA key is
>>> equivalent to, so the logical minimum for ECC looks like 'nistp256'.  The
>>> maximum is 521-bits on ECC (nistp521).
>>>
>>> Also move the mention of Ed25519 keys to their own bullet and clarify that they
>>> don't allow for a key length, as I think that's hardcoded in some capacity.
>>
>> following the comma-style of the rest of the document, the ECC part
>> should likely be read as curve25519 being the only acceptable curve,
>> which is 256 bits (roughtly 128 bit shannon entropy equivalent)
>>
>> that said, I'm not aware of any curves defined with a lower security
>> margin than this for OpenPGP in general. The known curves in the
>> ecosystem are
>>
>> let oid_to_psize oid =
>>    let psize = match oid with
>>      | "\x2b\x81\x04\x00\x23" -> 521                  (* nistp521 *)
>>      | "\x2b\x81\x04\x00\x22" -> 384                  (* nistp384 *)
>>      | "\x2a\x86\x48\xce\x3d\x03\x01\x07" -> 256      (* nistp256 *)
>>      | "\x2b\x24\x03\x03\x02\x08\x01\x01\x07" -> 256  (* brainpoolP256r1 *)
>>      | "\x2b\x24\x03\x03\x02\x08\x01\x01\x0b" -> 384  (* brainpoolP384r1 *)
>>      | "\x2b\x24\x03\x03\x02\x08\x01\x01\x0d" -> 512  (* brainpoolP512r1 *)
>>      | "\x2b\x81\x04\x00\x0a" -> 256                  (* secp256k1 *)
>>      | "\x2b\x06\x01\x04\x01\xda\x47\x0f\x01" -> 256  (* Ed25519 *)
>>      | _ -> failwith "Unknown OID"
>>
>
> By "only acceptable curve", do you mean we shouldn't allow the nistp* key
> types, only Ed25519?
>

Yes, the NIST curves are extremely suspect. I even have my doubts
about Ed25519; I personally only use it where a device has throughput
problems with RSA.

Cheers,
     R0b0t1

[gentoo-dev] [PATCH v2 08/11] glep-0063: Stop recommending DSA subkeys

[Michał Górny]

There is really no technical reason to use DSA these days, and we should
focus on having a single recommendation.  DSA keys are still permitted
via 'minimal' requirements.
---
 glep-0063.rst | 20 ++++++++------------
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/glep-0063.rst b/glep-0063.rst
index ab7cb79..e81c862 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -35,6 +35,9 @@ v1.1
 
   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
 ==========
 
@@ -122,26 +125,19 @@ their primary key).
        # when making an OpenPGP certification, use a stronger digest than the default SHA1:
        cert-digest-algo SHA256
 
-2. Primary key type RSA, 2048 bits (OpenPGP v4 key format or later)
-
-   This may require creating an entirely new key.
-
-3. Dedicated signing subkey of EITHER:
-
-   a. DSA 2048 bits exactly.
-
-   b. RSA 2048 bits exactly.
+2. Primary key and a dedicated signing subkey, both of type RSA, 2048 bits
+   (OpenPGP v4 key format or later)
 
-4. Key expiry:
+3. Key expiry:
 
    a. Primary key: 3 years maximum, expiry date renewed annually.
 
    b. Gentoo subkey: 1 year maximum, expiry date renewed every 6 months.
 
-5. Create a revocation certificate & store it hardcopy offsite securely
+4. Create a revocation certificate & store it hardcopy offsite securely
    (it's about ~300 bytes).
 
-6. Encrypted backup of your secret keys.
+5. Encrypted backup of your secret keys.
 
 Gentoo LDAP
 ===========
-- 
2.18.0

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

[Michał Górny]

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 <robbat2@gentoo.org>,
         Marissa Fischer <blogtodiffer@gmail.com>
 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

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 252 bytes --]

>>>>> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 452 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Joshua Kinard]

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
kumba@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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1813 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Matthias Maier]

[-- Attachment #1: Type: text/plain, Size: 589 bytes --]


On Thu, Jul  5, 2018, at 08:36 CDT, Michał Górny <mgorny@gentoo.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 850 bytes --]

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

[Marc Schiffbauer]

[-- Attachment #1: Type: text/plain, Size: 1055 bytes --]

* Matthias Maier schrieb am 05.07.18 um 15:51 Uhr:
> 
> On Thu, Jul  5, 2018, at 08:36 CDT, Michał Górny <mgorny@gentoo.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]

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 <mgorny@gentoo.org> 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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Marc Schiffbauer]

[-- Attachment #1: Type: text/plain, Size: 779 bytes --]

* 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 927 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Marc Schiffbauer]

[-- Attachment #1: Type: text/plain, Size: 1385 bytes --]

* 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1207 bytes --]

>>>>> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1766 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 570 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 979 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 554 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Marc Schiffbauer]

[-- Attachment #1: Type: text/plain, Size: 867 bytes --]

* 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1122 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 2133 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3030 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

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

[Matthias Maier]

[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]


On Thu, Jul  5, 2018, at 08:36 CDT, Michał Górny <mgorny@gentoo.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 850 bytes --]

[gentoo-dev] [PATCH v2 10/11] glep-0063: Require renewal 2 weeks before expiration

[Michał Górny]

Add a rule requesting renewal of keys at least two weeks before their
expiration date, in order to give services time to refresh.
---
 glep-0063.rst | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/glep-0063.rst b/glep-0063.rst
index 7455674..6874b81 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -32,6 +32,10 @@ v2
   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.
+
 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]_.
@@ -82,7 +86,10 @@ not be used to commit.
 
    b. Gentoo subkey: 1 year maximum
 
-4. Upload your key to the SKS keyserver rotation before usage!
+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
 ---------------
-- 
2.18.0

Re: [gentoo-dev] [PATCH v2 10/11] glep-0063: Require renewal 2 weeks before expiration

[Manuel Rüger]

[-- Attachment #1.1: Type: text/plain, Size: 1613 bytes --]

I disagree with adding this as a requirement.

Services should explicitly fail to work with expired GPG keys, key
renewal times should be at the key owner's descretion.
This should still be a recommendation that guarantees the key owner to
continue work without interruption.


Thanks,
Manuel

On 04.07.2018 12:24, Michał Górny wrote:
> Add a rule requesting renewal of keys at least two weeks before their
> expiration date, in order to give services time to refresh.
> ---
>  glep-0063.rst | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/glep-0063.rst b/glep-0063.rst
> index 7455674..6874b81 100644
> --- a/glep-0063.rst
> +++ b/glep-0063.rst
> @@ -32,6 +32,10 @@ v2
>    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.
> +
>  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]_.
> @@ -82,7 +86,10 @@ not be used to commit.
>  
>     b. Gentoo subkey: 1 year maximum
>  
> -4. Upload your key to the SKS keyserver rotation before usage!
> +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
>  ---------------
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 636 bytes --]

Re: [gentoo-dev] [PATCH v2 10/11] glep-0063: Require renewal 2 weeks before expiration

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 874 bytes --]

W dniu pią, 06.07.2018 o godzinie 10∶11 +0200, użytkownik Manuel Rüger
napisał:
> I disagree with adding this as a requirement.
> 
> Services should explicitly fail to work with expired GPG keys, key
> renewal times should be at the key owner's descretion.
> This should still be a recommendation that guarantees the key owner to
> continue work without interruption.
> 

They do.  That is why we need the updates to happen early enough so that
the services can sync.  It's not nice when Gentoo repository
distribution is stalled because a developer changed his key and not all
services have synced yet.

I've only recently hit the case when my important fix wasn't distributed
to users immediately (= more users hit severe breakage) because
a developer started using new key before all servers could sync it.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

[gentoo-dev] [PATCH v2 11/11] glep-0063: Disallow using DSA keys

[Michał Górny]

There really is no technical reason to use DSA keys and people who are
still using old DSA keys should finally replace them, so remove them
from the minimal requirements.
---
 glep-0063.rst | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/glep-0063.rst b/glep-0063.rst
index 6874b81..cd132a6 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -36,6 +36,8 @@ v2
   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]_.
@@ -74,11 +76,9 @@ not be used to commit.
 
 2. Primary key and a dedicated signing subkey, both of EITHER:
 
-   a. DSA, 2048-bit
-
-   b. RSA, >=2048 bits (OpenPGP v4 key format or later only)
+   a. RSA, >=2048 bits (OpenPGP v4 key format or later only)
 
-   c. ECC, curve 25519
+   b. ECC, curve 25519
 
 3. Key expiration:
 
-- 
2.18.0

[gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update; full text

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 8897 bytes --]

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 <robbat2@gentoo.org>,
        Andreas K. Hüttel <dilfridge@gentoo.org>,
        Marissa Fischer <blogtodiffer@gmail.com>
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-fpr@notations.openpgp.fifthhorseman.net=%g

       # when making an OpenPGP certification, use a stronger digest than the default SHA1:
       cert-digest-algo SHA256

2. Primary key and a dedicated signing subkey, both of type RSA, 2048 bits
   (OpenPGP v4 key format or later)

3. Key expiration renewal:

   a. Primary key: annual

   b. Gentoo subkey: every 6 months

4. Create a revocation certificate & store it hardcopy offsite securely
   (it's about ~300 bytes).

5. Encrypted backup of your secret keys.

Gentoo LDAP
===========

All Gentoo developers must list the complete fingerprint for their primary
keys in the "``gpgfingerprint``" LDAP field. It must be exactly 40 hex digits,
uppercase, with optional spaces every 8 hex digits. Regular expression for
validation::

    ^([[:space:]]*[[:xdigit:]]{8}){5}$

The prior "``gpgkey``" field will be removed, as it is a subset
of the fingerprint field. In any place that presently displays
the "``gpgkey``" field, the last 16 hex digits of the fingerprint should
be displayed instead.

Backwards Compatibility
=======================

There is no consistent standard for GPG usage in Gentoo to date. There is
conflicting information in the Devmanual [#DEVMANUAL-MANIFEST]_ and the GnuPG
Gentoo user guide [#GNUPG-USER]_. As there is little enforcement of Manifest
signing and very little commit signing to date, there are no backwards
compatibility concerns.

External documentation
======================

Much of the above was driven by the following:

* NIST SP 800-57 recommendations [#NISTSP800571]_, [#NISTSP800572]_

* Debian GPG documentation [#DEBIANGPG]_

* RiseUp.net OpenPGP best practices [#RISEUP]_

* ENISA Algorithms, Key Sizes and Parameters Report 2013 [#ENISA2013]_

References
==========

.. [#GNUPG-FAQ-11-4] GnuPG FAQ: Why doesn’t GnuPG default to using RSA-4096?
   (https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096)

.. [#DEBIANGPG] Debian GPG documentation
   (https://wiki.debian.org/Keysigning)

.. [#EKAIA] Ana's blog: Creating a new GPG key
   (http://ekaia.org/blog/2009/05/10/creating-new-gpgkey/)

.. [#RISEUP] RiseUp.net OpenPGP best practices
   (https://help.riseup.net/en/security/message-security/openpgp/best-practices)

.. [#DEVMANUAL-MANIFEST] Gentoo Development Guide: Manifest
   (http://devmanual.gentoo.org/general-concepts/manifest/index.html)

.. [#GNUPG-USER] GnuPG Gentoo User Guide
   (http://www.gentoo.org/doc/en/gnupg-user.xml)

.. [#NISTSP800571] NIST SP 800-57: Recommendation for Key Management:
   Part 1: General (Revision 3)
   (http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf)

.. [#NISTSP800572] NIST SP 800-57: Recommendation for Key Management:
   Part 2: Best Practices for Key Management Organization
   (http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part2.pdf)

.. [#ISSUER-ANNOTATE] Including the entire fingerprint of the issuer
  in an OpenPGP certification
  (http://thread.gmane.org/gmane.mail.notmuch.general/3721/focus=7234)

.. [#ENISA2013] ENISA Algorithms, Key Sizes and Parameters Report,
   2013 recommendations, version 1.0 (October 2013)
   (https://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report)

Copyright
=========
Copyright (c) 2013 by Robin Hugh Johnson, Andreas K. Hüttel, Marissa Fischer.

This work is licensed under the Creative Commons Attribution-ShareAlike 3.0
Unported License.  To view a copy of this license, visit
http://creativecommons.org/licenses/by-sa/3.0/.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update; full text

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 8804 bytes --]

Updated complete text after applying two more patches on k_f's request.

---
GLEP: 63
Title: Gentoo OpenPGP policies
Author: Robin H. Johnson <robbat2@gentoo.org>,
        Andreas K. Hüttel <dilfridge@gentoo.org>,
        Marissa Fischer <blogtodiffer@gmail.com>
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-fpr@notations.openpgp.fifthhorseman.net=%g

       # when making an OpenPGP certification, use a stronger digest than the default SHA1:
       cert-digest-algo SHA256

2. Primary key and the signing subkey are both of type RSA, 2048 bits
   (OpenPGP v4 key format or later)

3. Key expiration renewal:

   a. Primary key: annual

   b. Signing subkey: every 6 months

4. Create a revocation certificate & store it hardcopy offsite securely
   (it's about ~300 bytes).

5. Encrypted backup of your secret keys.

Gentoo LDAP
===========

All Gentoo developers must list the complete fingerprint for their primary
keys in the "``gpgfingerprint``" LDAP field. It must be exactly 40 hex digits,
uppercase, with optional spaces every 8 hex digits. Regular expression for
validation::

    ^([[:space:]]*[[:xdigit:]]{8}){5}$

The prior "``gpgkey``" field will be removed, as it is a subset
of the fingerprint field. In any place that presently displays
the "``gpgkey``" field, the last 16 hex digits of the fingerprint should
be displayed instead.

Backwards Compatibility
=======================

There is no consistent standard for GPG usage in Gentoo to date. There is
conflicting information in the Devmanual [#DEVMANUAL-MANIFEST]_ and the GnuPG
Gentoo user guide [#GNUPG-USER]_. As there is little enforcement of Manifest
signing and very little commit signing to date, there are no backwards
compatibility concerns.

External documentation
======================

Much of the above was driven by the following:

* NIST SP 800-57 recommendations [#NISTSP800571]_, [#NISTSP800572]_

* Debian GPG documentation [#DEBIANGPG]_

* RiseUp.net OpenPGP best practices [#RISEUP]_

* ENISA Algorithms, Key Sizes and Parameters Report 2013 [#ENISA2013]_

References
==========

.. [#GNUPG-FAQ-11-4] GnuPG FAQ: Why doesn’t GnuPG default to using RSA-4096?
   (https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096)

.. [#DEBIANGPG] Debian GPG documentation
   (https://wiki.debian.org/Keysigning)

.. [#EKAIA] Ana's blog: Creating a new GPG key
   (http://ekaia.org/blog/2009/05/10/creating-new-gpgkey/)

.. [#RISEUP] RiseUp.net OpenPGP best practices
   (https://help.riseup.net/en/security/message-security/openpgp/best-practices)

.. [#DEVMANUAL-MANIFEST] Gentoo Development Guide: Manifest
   (http://devmanual.gentoo.org/general-concepts/manifest/index.html)

.. [#GNUPG-USER] GnuPG Gentoo User Guide
   (http://www.gentoo.org/doc/en/gnupg-user.xml)

.. [#NISTSP800571] NIST SP 800-57: Recommendation for Key Management:
   Part 1: General (Revision 3)
   (http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf)

.. [#NISTSP800572] NIST SP 800-57: Recommendation for Key Management:
   Part 2: Best Practices for Key Management Organization
   (http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part2.pdf)

.. [#ISSUER-ANNOTATE] Including the entire fingerprint of the issuer
  in an OpenPGP certification
  (http://thread.gmane.org/gmane.mail.notmuch.general/3721/focus=7234)

.. [#ENISA2013] ENISA Algorithms, Key Sizes and Parameters Report,
   2013 recommendations, version 1.0 (October 2013)
   (https://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report)

Copyright
=========
Copyright (c) 2013 by Robin Hugh Johnson, Andreas K. Hüttel, Marissa Fischer.

This work is licensed under the Creative Commons Attribution-ShareAlike 3.0
Unported License.  To view a copy of this license, visit
http://creativecommons.org/licenses/by-sa/3.0/.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update; full text

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 319 bytes --]

>>>>> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update; full text

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 796 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update; full text

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 1206 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update; full text

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 1384 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update; full text

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1429 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update; full text

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 898 bytes --]

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   : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 1113 bytes --]

Re: [gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update; full text

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 611 bytes --]

>>>>> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

[gentoo-dev] [PATCH 12/13] glep-0063: 'Gentoo subkey' → 'Signing subkey'

[Michał Górny]

Remove the last occurence that might suggest that developers are
expected to use a dedicated subkey for Gentoo.

Suggested-by: Kristian Fiskerstrand <k_f@gentoo.org>
---
 glep-0063.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/glep-0063.rst b/glep-0063.rst
index cd132a6..d3e12e0 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -84,7 +84,7 @@ not be used to commit.
 
    a. Primary key: 3 years maximum
 
-   b. Gentoo subkey: 1 year maximum
+   b. Signing subkey: 1 year maximum
 
 4. Key expiration date renewed at least 2 weeks before the previous
    expiration date.
@@ -148,7 +148,7 @@ their primary key).
 
    a. Primary key: annual
 
-   b. Gentoo subkey: every 6 months
+   b. Signing subkey: every 6 months
 
 4. Create a revocation certificate & store it hardcopy offsite securely
    (it's about ~300 bytes).
-- 
2.18.0

[gentoo-dev] [PATCH 13/13] glep-0063: Split out the signing subkey into a separation point

[Michał Górny]

Reword the specification to express the requirement for separate signing
subkey more verbosely.  Replace the ambiguous term 'dedicated' with
clear explanation that it needs to be different from the primary key
and not used for other purposes.

Suggested-by: Kristian Fiskerstrand <k_f@gentoo.org>
---
 glep-0063.rst | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/glep-0063.rst b/glep-0063.rst
index d3e12e0..2f4e7f8 100644
--- a/glep-0063.rst
+++ b/glep-0063.rst
@@ -74,22 +74,25 @@ not be used to commit.
 
        personal-digest-preferences SHA256
 
-2. Primary key and a dedicated signing subkey, both of EITHER:
+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
 
-3. Key expiration:
+4. Key expiration:
 
    a. Primary key: 3 years maximum
 
    b. Signing subkey: 1 year maximum
 
-4. Key expiration date renewed at least 2 weeks before the previous
+5. Key expiration date renewed at least 2 weeks before the previous
    expiration date.
 
-5. Upload your key to the SKS keyserver rotation before usage!
+6. Upload your key to the SKS keyserver rotation before usage!
 
 Recommendations
 ---------------
@@ -141,7 +144,7 @@ their primary key).
        # when making an OpenPGP certification, use a stronger digest than the default SHA1:
        cert-digest-algo SHA256
 
-2. Primary key and a dedicated signing subkey, both of type RSA, 2048 bits
+2. Primary key and the signing subkey are both of type RSA, 2048 bits
    (OpenPGP v4 key format or later)
 
 3. Key expiration renewal:
-- 
2.18.0