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