Catch 22 in ECC support of OpenPGP?
openpgp at brainhub.org
Fri Jan 31 07:17:18 CET 2014
On 01/30/2014 07:46 PM, NIIBE Yutaka wrote:
> Hello, Andrey and Werner,
> Cc-ed to GnuPG Development List.
> I'm currently considering adding other curves and EdDSA signature
> scheme to Gnuk. I'm also considering update of GnuPG's smartcard
> support for ECC.
> I think that adding curves would be no problem against RFC6637, as OID
> is unique. Currently, development version of GnuPG supports curves
> defined by RFC6637 as well as three curves of Brainpool, and
> I think that adding new signature scheme requires its algorithm ID.
> Writing this mail today, I did some research. Then, I found the
> discussion in OpenPGP at ietf.org:
> (1) Possible algorithm ID 22 for ECDH+ECDSA:
> (2) Possible algorithm ID 22 for EdDSA:
> It's better to sort it out now.
> Algorithm ID 22 for ECDH+ECDSA
> Algorithm ID 23 for EdDSA
> Sorry for interference, but I need Algorithm ID 22 (and 23) defined,
I am fine with 22.
I think it's premature to think that the 23 EdDSA is ready to go along
the side of ECDSA. I am not saying that this will never happen, but
rather that this needs to be discussed and benefits stated. ( Would it
work to perhaps claim some higher-numbered ID in the mean time? If it
turns to be popular, we can "upgrade" it later to the permanent number)
As for compact representation, I recently updated
http://http://tools.ietf.org/html/draft-jivsov-ecc-compact to include
curves other than simple Weierstrass curves. I would recommend it as a
format for OpenPGP. NIIBE, perhaps you could double-check that you are
OK with the representation for Curve25519.
To use the draft-jivsov-ecc-compact in OpenPGP there could be a separate
draft, but its value will be mostly procedural because it will basically
refer the reader to the draft-jivsov-ecc-compact (so one knows what to
do without such a second draft already when, for example, a single "x"
More information about the Gnupg-devel