[gentoo-dev] [PATCH 0/4] GLEP 63: clean up, and reduce key size to RSA-2048

[gentoo-dev] [PATCH 0/4] GLEP 63: clean up, and reduce key size to RSA-2048

[Michał Górny]

Hi, everyone.

Here's a series of patches for GLEP 63 (key policies).  The first three
patches are merely editorial changes.  The fourth is an actual
recommended policy change.

The editorial changes are:

1. Using 'OpenPGP' instead of 'GPG' where appropriate.

2. Replacing 'RSAv4' with more correct term.

3. Clarifying the sentence on minimal key requirement to make it clear
   that dedicated signing subkey is also part of it.

The policy change is changing the recommendation from RSA-4096
to RSA-2048.  This does not require developers to reroll their RSA-4096
keys but aims to prevent people unnecessarily replacing RSA-2048 with
RSA-4096.

The new recommendation matches what GnuPG FAQ suggests [1] (see 11.4,
11.5).  Long story short, RSA-4096 is only a little stronger than
RSA-2048 while it is much slower.  If someone really wants to use it,
sure; but generally we shouldn't be encouraging people to use it.

[1]:https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096

--
Best regards,
Michał Górny

Michał Górny (4):
  glep-0063: Use 'OpenPGP' as appropriate
  glep-0063: RSAv4 -> OpenPGP v4 key format
  glep-0063: Clarify dedicated signing subkey in minimal reqs
  glep-0063: Change the recommended RSA key size to 2048 bits

 glep-0063.rst | 44 ++++++++++++++++++++++++++++----------------
 1 file changed, 28 insertions(+), 16 deletions(-)

-- 
2.18.0

[gentoo-dev] [PATCH 1/4] 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 2/4] 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 3/4] 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

[gentoo-dev] [PATCH 4/4] 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 0082edd..f1512b3 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-02
 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
 ==========
 
@@ -101,7 +110,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. Root key type RSA, 2048 bits (OpenPGP v4 key format or later)
 
    This may require creating an entirely new key.
 
@@ -109,7 +118,7 @@ Recommendations
 
    a. DSA 2048 bits exactly.
 
-   b. RSA 4096 bits exactly.
+   b. RSA 2048 bits exactly.
 
 4. Key expiry:
 
@@ -162,6 +171,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

Re: [gentoo-dev] [PATCH 0/4] GLEP 63: clean up, and reduce key size to RSA-2048

[Aaron Bauman]

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

On Tuesday, July 3, 2018 9:29:53 AM EDT Michał Górny wrote:
> Hi, everyone.
> 
> Here's a series of patches for GLEP 63 (key policies).  The first three
> patches are merely editorial changes.  The fourth is an actual
> recommended policy change.
> 
> The editorial changes are:
> 
> 1. Using 'OpenPGP' instead of 'GPG' where appropriate.
> 
> 2. Replacing 'RSAv4' with more correct term.
> 
> 3. Clarifying the sentence on minimal key requirement to make it clear
>    that dedicated signing subkey is also part of it.
> 
> The policy change is changing the recommendation from RSA-4096
> to RSA-2048.  This does not require developers to reroll their RSA-4096
> keys but aims to prevent people unnecessarily replacing RSA-2048 with
> RSA-4096.
> 
> The new recommendation matches what GnuPG FAQ suggests [1] (see 11.4,
> 11.5).  Long story short, RSA-4096 is only a little stronger than
> RSA-2048 while it is much slower.  If someone really wants to use it,
> sure; but generally we shouldn't be encouraging people to use it.
> 
> [1]:https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096
> 
> --
> Best regards,
> Michał Górny
> 
> Michał Górny (4):
>   glep-0063: Use 'OpenPGP' as appropriate
>   glep-0063: RSAv4 -> OpenPGP v4 key format
>   glep-0063: Clarify dedicated signing subkey in minimal reqs
>   glep-0063: Change the recommended RSA key size to 2048 bits
> 
>  glep-0063.rst | 44 ++++++++++++++++++++++++++++----------------
>  1 file changed, 28 insertions(+), 16 deletions(-)

Patches look good to me.  I think now would be a good time to address other 
verbage too.  e.g. recommendations should be requirements etc

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

Re: [gentoo-dev] [PATCH 0/4] GLEP 63: clean up, and reduce key size to RSA-2048

[Aaron Bauman]

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

On Tuesday, July 3, 2018 12:40:57 PM EDT Aaron Bauman wrote:
> On Tuesday, July 3, 2018 9:29:53 AM EDT Michał Górny wrote:
> > Hi, everyone.
> > 
> > Here's a series of patches for GLEP 63 (key policies).  The first three
> > patches are merely editorial changes.  The fourth is an actual
> > recommended policy change.
> > 
> > The editorial changes are:
> > 
> > 1. Using 'OpenPGP' instead of 'GPG' where appropriate.
> > 
> > 2. Replacing 'RSAv4' with more correct term.
> > 
> > 3. Clarifying the sentence on minimal key requirement to make it clear
> > 
> >    that dedicated signing subkey is also part of it.
> > 
> > The policy change is changing the recommendation from RSA-4096
> > to RSA-2048.  This does not require developers to reroll their RSA-4096
> > keys but aims to prevent people unnecessarily replacing RSA-2048 with
> > RSA-4096.
> > 
> > The new recommendation matches what GnuPG FAQ suggests [1] (see 11.4,
> > 11.5).  Long story short, RSA-4096 is only a little stronger than
> > RSA-2048 while it is much slower.  If someone really wants to use it,
> > sure; but generally we shouldn't be encouraging people to use it.
> > 
> > [1]:https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096
> > 
> > --
> > Best regards,
> > Michał Górny
> > 
> > Michał Górny (4):
> >   glep-0063: Use 'OpenPGP' as appropriate
> >   glep-0063: RSAv4 -> OpenPGP v4 key format
> >   glep-0063: Clarify dedicated signing subkey in minimal reqs
> >   glep-0063: Change the recommended RSA key size to 2048 bits
> >  
> >  glep-0063.rst | 44 ++++++++++++++++++++++++++++----------------
> >  1 file changed, 28 insertions(+), 16 deletions(-)
> 
> Patches look good to me.  I think now would be a good time to address other
> verbage too.  e.g. recommendations should be requirements etc

To clarify.  I think this patchset it good as it is.  I can create a new 
patchset with recommendations for the things I mentioned above.

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

Re: [gentoo-dev] [PATCH 0/4] GLEP 63: clean up, and reduce key size to RSA-2048

[Michał Górny]

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

W dniu wto, 03.07.2018 o godzinie 12∶42 -0400, użytkownik Aaron Bauman
napisał:
> On Tuesday, July 3, 2018 12:40:57 PM EDT Aaron Bauman wrote:
> > On Tuesday, July 3, 2018 9:29:53 AM EDT Michał Górny wrote:
> > > Hi, everyone.
> > > 
> > > Here's a series of patches for GLEP 63 (key policies).  The first three
> > > patches are merely editorial changes.  The fourth is an actual
> > > recommended policy change.
> > > 
> > > The editorial changes are:
> > > 
> > > 1. Using 'OpenPGP' instead of 'GPG' where appropriate.
> > > 
> > > 2. Replacing 'RSAv4' with more correct term.
> > > 
> > > 3. Clarifying the sentence on minimal key requirement to make it clear
> > > 
> > >    that dedicated signing subkey is also part of it.
> > > 
> > > The policy change is changing the recommendation from RSA-4096
> > > to RSA-2048.  This does not require developers to reroll their RSA-4096
> > > keys but aims to prevent people unnecessarily replacing RSA-2048 with
> > > RSA-4096.
> > > 
> > > The new recommendation matches what GnuPG FAQ suggests [1] (see 11.4,
> > > 11.5).  Long story short, RSA-4096 is only a little stronger than
> > > RSA-2048 while it is much slower.  If someone really wants to use it,
> > > sure; but generally we shouldn't be encouraging people to use it.
> > > 
> > > [1]:https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096
> > > 
> > > --
> > > Best regards,
> > > Michał Górny
> > > 
> > > Michał Górny (4):
> > >   glep-0063: Use 'OpenPGP' as appropriate
> > >   glep-0063: RSAv4 -> OpenPGP v4 key format
> > >   glep-0063: Clarify dedicated signing subkey in minimal reqs
> > >   glep-0063: Change the recommended RSA key size to 2048 bits
> > >  
> > >  glep-0063.rst | 44 ++++++++++++++++++++++++++++----------------
> > >  1 file changed, 28 insertions(+), 16 deletions(-)
> > 
> > Patches look good to me.  I think now would be a good time to address other
> > verbage too.  e.g. recommendations should be requirements etc
> 
> To clarify.  I think this patchset it good as it is.  I can create a new 
> patchset with recommendations for the things I mentioned above.

Please do.  I tried to keep this to stuff that's not likely to cause
much of a bikeshed because I feel like stopping to tell people to do
RSA-4096 is somewhat urgent, especially now that people are being asked
to update their keys all over the 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 5/4] glep-0063: Allow ECC keys

[Michał Górny]

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

diff --git a/glep-0063.rst b/glep-0063.rst
index f1512b3..8714204 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
 ==========
 
@@ -60,6 +62,8 @@ Bare minimum requirements
 
    b. RSA, >=2048 bits (OpenPGP v4 key format or later only)
 
+   c. ECC
+
 3. Key expiry: 5 years maximum
 
 4. Upload your key to the SKS keyserver rotation before usage!
-- 
2.18.0

Re: [gentoo-dev] [PATCH 5/4] glep-0063: Allow ECC keys

[Kristian Fiskerstrand]

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

On 07/04/2018 09:22 AM, Michał Górny wrote:
> +   c. ECC

Likely should not blanket accept ECC for various reasons. For one thing
the curves we likely would want to accept are not standardized, so you
have interoperability issues.

The hardware situation is improving somewhat on these, so that is less
of a concern now than back in the day.

But there aren't really very strong arguments in favor of ecc, and in
the case of quantum computation there less protection offered from ecc
due to smaller key sizes.

We also keep gnupg 1.4 in tree that does not, and will not, support ecc.

-- 
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 5/4] glep-0063: Allow ECC keys

[Michał Górny]

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

W dniu śro, 04.07.2018 o godzinie 09∶49 +0200, użytkownik Kristian
Fiskerstrand napisał:
> On 07/04/2018 09:22 AM, Michał Górny wrote:
> > +   c. ECC
> 
> Likely should not blanket accept ECC for various reasons. For one thing
> the curves we likely would want to accept are not standardized, so you
> have interoperability issues.
> 
> The hardware situation is improving somewhat on these, so that is less
> of a concern now than back in the day.
> 
> But there aren't really very strong arguments in favor of ecc, and in
> the case of quantum computation there less protection offered from ecc
> due to smaller key sizes.
> 
> We also keep gnupg 1.4 in tree that does not, and will not, support ecc.

Well, we have developers using ECC (Curve 25519, to be specific).
I don't really know enough about this to judge but we either need to
allow at least this, or convince those devs to change to RSA.

Would one of the following wordings be better:

a) ECC, Curve 25519[, ...]

b) ECC, curves supported by GnuPG version ...

Alternatively, do you have other suggestions?

-- 
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 5/4] glep-0063: Allow ECC keys

[Kristian Fiskerstrand]

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

On 07/04/2018 09:54 AM, Michał Górny wrote:
>> We also keep gnupg 1.4 in tree that does not, and will not, support ecc.
> Well, we have developers using ECC (Curve 25519, to be specific).
> I don't really know enough about this to judge but we either need to
> allow at least this, or convince those devs to change to RSA.

incidentally curve25519 is the one I'm thinking of that isn't
standardized, although it is part of current draft version of rfc4880bis
(but WG is stalled so no update expected any time soon there).
NIST/brainpool are included in RFC6637, but we wouldn't want to accept
them for various reasons.

There are good reasons these are not provided in the regular interface
of gnupg, but requires --expert

-- 
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 5/4] glep-0063: Allow ECC keys

[Michał Górny]

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

W dniu śro, 04.07.2018 o godzinie 10∶01 +0200, użytkownik Kristian
Fiskerstrand napisał:
> On 07/04/2018 09:54 AM, Michał Górny wrote:
> > > We also keep gnupg 1.4 in tree that does not, and will not, support ecc.
> > 
> > Well, we have developers using ECC (Curve 25519, to be specific).
> > I don't really know enough about this to judge but we either need to
> > allow at least this, or convince those devs to change to RSA.
> 
> incidentally curve25519 is the one I'm thinking of that isn't
> standardized, although it is part of current draft version of rfc4880bis
> (but WG is stalled so no update expected any time soon there).
> NIST/brainpool are included in RFC6637, but we wouldn't want to accept
> them for various reasons.
> 
> There are good reasons these are not provided in the regular interface
> of gnupg, but requires --expert
> 

To be honest, I have mixed feelings here.

While I agree interoperability is a problem in general, I'm not sure if
it's really a problem this large.  I agree that we shouldn't recommend
ECC but should we ban it entirely?

Things to note:

1. I suppose the ECC/cv25519 packets won't change in incompatible manner
at this point.

2. Hardware incompatibility issues are not really relevant to us but to
the person using the key.

3. Developer keys are mostly for internal use, while the majority of
users verify only the infra signatures, so I don't think we have to be
that concerned about interoperability of the algos, provided that it
works for infra purposes.

-- 
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 5/4] glep-0063: Allow ECC keys

[Kristian Fiskerstrand]

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

On 07/04/2018 10:42 AM, Michał Górny wrote:
> 1. I suppose the ECC/cv25519 packets won't change in incompatible manner
> at this point.

It being implemented in gnupg-2-2 is a good indication it won't be
allowed to change at this point

> 
> 2. Hardware incompatibility issues are not really relevant to us but to
> the person using the key.

It is relevant to us to the extent of discussion for hardware token for devs

> 
> 3. Developer keys are mostly for internal use, while the majority of
> users verify only the infra signatures, so I don't think we have to be
> that concerned about interoperability of the algos, provided that it
> works for infra purposes.

This depends on the discussion of rsync vs git, if you expect end-users
to verify git commits from developers directly you require them to use
the 2.2 branch, whereby some server users prefer 1.4 for its smaller
footprint etc. If we conclude that the git repo is internal and not to
be exposed to end-users per se, but distribution happens in curated git
or rsync I agree it is not an issue.

-- 
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 5/4] glep-0063: Allow ECC keys

[Michał Górny]

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

W dniu śro, 04.07.2018 o godzinie 10∶51 +0200, użytkownik Kristian
Fiskerstrand napisał:
> On 07/04/2018 10:42 AM, Michał Górny wrote:
> > 1. I suppose the ECC/cv25519 packets won't change in incompatible manner
> > at this point.
> 
> It being implemented in gnupg-2-2 is a good indication it won't be
> allowed to change at this point
> 
> > 
> > 2. Hardware incompatibility issues are not really relevant to us but to
> > the person using the key.
> 
> It is relevant to us to the extent of discussion for hardware token for devs
> 

Sure but I think that's the matter of 'recommended' vs 'minimal'.
But that part of the GLEP probably needs to change/be clarified as well.

> > 
> > 3. Developer keys are mostly for internal use, while the majority of
> > users verify only the infra signatures, so I don't think we have to be
> > that concerned about interoperability of the algos, provided that it
> > works for infra purposes.
> 
> This depends on the discussion of rsync vs git, if you expect end-users
> to verify git commits from developers directly you require them to use
> the 2.2 branch, whereby some server users prefer 1.4 for its smaller
> footprint etc. If we conclude that the git repo is internal and not to
> be exposed to end-users per se, but distribution happens in curated git

I honestly don't think Gentoo is the distribution where we let people
stay with obsolete versions for 'smaller footprint'.

-- 
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 5/4] glep-0063: Allow ECC keys

[Kristian Fiskerstrand]

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

On 07/04/2018 11:09 AM, Michał Górny wrote:
> I honestly don't think Gentoo is the distribution where we let people
> stay with obsolete versions for 'smaller footprint'.

1.4 isn't obsolete, it is still maintained as separate branch upstream.

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