Hi Niibe,
Thanks for working on that! Having recently read the MPI section there
are definitely some things that could be improved.
But I want to comment on one particular thing:
On 03.03.2021 04:26, NIIBE Yutaka wrote:
When an SOS data object is handled as an MPI, it would look "strange"
as it may include preceding zeros, which is not allowed in well-formed
MPI.
Actually from my reading of section 3.2 [0] preceding zeros are not
explicitly disallowed in the spec. It's just the preceding zeros should
not count towards MPI length:
The length field of an MPI describes the length starting from its
most significant non-zero bit. Thus, the MPI [00 02 01] is not
formed correctly. It should be [00 01 01].
[0]: https://tools.ietf.org/html/rfc4880#section-3.2
It doesn't say that [00 01 00 01] is invalid, just that the length
should not include leading zeros: [00 02 01].
(Unless I'm reading something wrong: please correct me if that's the fact).
For the record I thought that the "byte length" (not MPI bit length)
would be more appropriate because for all purposes the emitted stream
will always contain full bytes anyway but I do understand you want to
keep the backwards compatibility. Even though maybe new curves can use
this new byte-length SOS.
Calculating bits correctly seems to be more complex than necessary with
potential for confusion: I've reported it to GnuPG [1] and Sequoia [2].
[1]: https://lists.gnupg.org/pipermail/gnupg-devel/2021-March/034735.html
[2]: https://gitlab.com/sequoia-pgp/sequoia/-/issues/682
Kind regards,
Wiktor
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp