There are several active documents also defining compact representation. After the discussion regarding HPKE there was a suggestion EDHOC should define a compract format that could be reused by other protocols. That was done in an Appendix. https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-12#page-67
Also as an outcome of the HPKE discussions Dan Harkins has written on compact representation for HPKE submitted to CFRG. This also defines a a general format than can be reused by other protocols. https://datatracker.ietf.org/doc/draft-harkins-cfrg-dnhpke/ > the support for 'regular' (SEC1) compressed curves is more widespread. What is support in this case? An implementation can just use one of the values "02" and "03" or flip a coin. If you have support of 'regular' (SEC1) compressed curves, then compact representation is trivial. Cheers, John From: TLS <[email protected]> on behalf of Andrey Jivsov <[email protected]> Date: Tuesday, 26 October 2021 at 07:15 To: Carl Mehner <[email protected]> Cc: IETF TLS <[email protected]> Subject: Re: [TLS] Point Compression Do we have evidence that "02 <x>" or "03 <x>" is more widespread than <x> for NIST curves? I haven't seen "02 <x>" or "03 <x>" in deployed products in TLS / X.509 at all. So, I feel that for TLS space the slate is clean regarding compression. X25519 uses one coordinate, which is simiiar to doing <x> for NIST curves...
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
