We will need this for 1.9

What kind of API should we offer?
(1) offering something like q@comp name for gcry_mpi_ec_get_mpi
But...
If the intended use case will be in create_request function in gpg/sm/certreqgen.c, the 'q' is already generated in the form of SEXP.
It is up to an application (gpgsm), to convert non-compressed point representation to compressed point representation, here.

(2) keygen supporting (flag comp) for classic curves to ask compressed point representation for q, and support of compressed point representation for other places.

Perhaps, (2)?

I'm afraid this will introduce requirement of libgcrypt 1.9 for gpg.

Besides,

(3) _gcry_ecc_os2ec in libgcrypt/cipher/ecc-misc.c should be modified to support parsing compressed representation.

I think that retrieving a parameter in compressed format is all what we need as per API.

Creating is not that useful - we prefer modern curves anyway.

• compressed representation of EC point can be used in:
  • public key
  • (exporting) private key
  • signature
  • ECDH ephemeral key
• Accepting compressed representation,for the initial implementation, I'd like to limit our effort for curves of NIST and Brainpool, except NIST P-224, which p = 3 mod 4.

For the reference of full mod_sqrt, see https://eli.thegreenplace.net/2009/03/07/computing-modular-square-roots-in-python/

What is the state of this bug? Reading is implemented - do we really need writing (maybe to support certain smartcards)?

Reading compressed point (in keys) is supported (except for NIST P-224). When curve point is represented in compressed format, it is correctly interpreted now. So, for example, I think that with 1.9.0, gpgsm can handle certificate which uses compressed format in its curve point representation.

(I was wrong about signature (ECDSA signature (R,S) is composed by both integers. So, it's irrelevant. I had thought about EdDSA, which R is curve point, but it specifically has its own little-endian opaque format for R).)

Key generation never generate a key with compressed point (yet).

Please note that:
Currently, in gpgsm (sm/certreqgen.c), in the create_request function, sigkey is retrieved by gpgsm_agent_readkey, and curve point is extracted by get_ecc_q_from_canon_sexp from SEXP representation, then the curve point is used by ksba_certreq_add_extention in DER format. The curve point is passed with no interpretation or conversion, as is. (No use of gcry_mpi_ec_get_mpi here.)

When key generation with compressed point will be supported and it's used as sigkey, subjectKeyIdentifier will have compressed point representation.

Umm... I'm afraid, I would missed the point or have misunderstanding...