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 <tls-boun...@ietf.org> on behalf of Andrey Jivsov <cry...@brainhub.org> Date: Tuesday, 26 October 2021 at 07:15 To: Carl Mehner <c...@cem.me> Cc: IETF TLS <tls@ietf.org> 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 TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
