Re: [gentoo-dev] [PATCH 5/4] glep-0063: Allow ECC keys
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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 5/4] glep-0063: Allow ECC keys
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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 5/4] glep-0063: Allow ECC keys
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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 5/4] glep-0063: Allow ECC keys
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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 5/4] glep-0063: Allow ECC keys
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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 5/4] glep-0063: Allow ECC keys
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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 5/4] glep-0063: Allow ECC keys
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 signature.asc Description: OpenPGP digital signature
[gentoo-dev] [PATCH 5/4] glep-0063: Allow ECC keys
--- 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
