* Wiktor Kwapisiewicz:
[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
This isn't really specific to ECC. RSA has a similar issue. I've
asked about this before, but it seems the message got lost at the
time.
From: Florian Weimer <fw(_at_)deneb(_dot_)enyo(_dot_)de>
To: ietf-openpgp(_at_)imc(_dot_)org
Subject: Implementations do not seem to use RFC 3447 PKCS#1 encoding
Date: Thu, 02 Apr 2020 22:56:26 +0200
Message-ID: <87a73tk3np(_dot_)fsf(_at_)mid(_dot_)deneb(_dot_)enyo(_dot_)de>
It seems that some implementations drop leading zeros from MPIs,
violating the octet string length requirements in RFC 3447, which are
also repeated in section 13.1 of RFC 4880.
This is likely the result of a rule in section 3.2 of RFC 4880 that
leading zeros in MPIs should not be encoded.
It's not possible to follow both rules at the same time.
Has this come up before?
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp