| 1 |
W dniu śro, 04.07.2018 o godzinie 10∶01 +0200, użytkownik Kristian |
| 2 |
Fiskerstrand napisał: |
| 3 |
> On 07/04/2018 09:54 AM, Michał Górny wrote: |
| 4 |
> > > We also keep gnupg 1.4 in tree that does not, and will not, support ecc. |
| 5 |
> > |
| 6 |
> > Well, we have developers using ECC (Curve 25519, to be specific). |
| 7 |
> > I don't really know enough about this to judge but we either need to |
| 8 |
> > allow at least this, or convince those devs to change to RSA. |
| 9 |
> |
| 10 |
> incidentally curve25519 is the one I'm thinking of that isn't |
| 11 |
> standardized, although it is part of current draft version of rfc4880bis |
| 12 |
> (but WG is stalled so no update expected any time soon there). |
| 13 |
> NIST/brainpool are included in RFC6637, but we wouldn't want to accept |
| 14 |
> them for various reasons. |
| 15 |
> |
| 16 |
> There are good reasons these are not provided in the regular interface |
| 17 |
> of gnupg, but requires --expert |
| 18 |
> |
| 19 |
|
| 20 |
To be honest, I have mixed feelings here. |
| 21 |
|
| 22 |
While I agree interoperability is a problem in general, I'm not sure if |
| 23 |
it's really a problem this large. I agree that we shouldn't recommend |
| 24 |
ECC but should we ban it entirely? |
| 25 |
|
| 26 |
Things to note: |
| 27 |
|
| 28 |
1. I suppose the ECC/cv25519 packets won't change in incompatible manner |
| 29 |
at this point. |
| 30 |
|
| 31 |
2. Hardware incompatibility issues are not really relevant to us but to |
| 32 |
the person using the key. |
| 33 |
|
| 34 |
3. Developer keys are mostly for internal use, while the majority of |
| 35 |
users verify only the infra signatures, so I don't think we have to be |
| 36 |
that concerned about interoperability of the algos, provided that it |
| 37 |
works for infra purposes. |
| 38 |
|
| 39 |
-- |
| 40 |
Best regards, |
| 41 |
Michał Górny |
Archives