Re: [openpgp] ECC point encoding and "flag byte"

[Florian Weimer <[e-mail]>]

* 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 <[e-mail]>
To: [e-mail]
Subject: Implementations do not seem to use RFC 3447 PKCS#1 encoding
Date: Thu, 02 Apr 2020 22:56:26 +0200
Message-ID: <[e-mail]>

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?