Question about EdDSA value s MPI in signatures

[Wiktor Kwapisiewicz]

Hello,

I've been recently analyzing EdDSA signatures and found one interesting 
case. Not sure if I did my analysis correctly or if that's a bug in the 
beta but I'd be really glad if someone helped me to understand what's 
happening.

One signature piqued my interest. It's attached to this e-mail:

https://lists.gnupg.org/pipermail/gnupg-devel/2021-February/034715.html

The relevant portion of the signature that looks suspicious is the 
"EdDSA value s, in MPI" [0] at the end (00000055):

00000031     9b                                        digest_prefix1
00000032        5b                                     digest_prefix2
00000033           00 fe                               eddsa_sig_r_len
00000035                 2b f9 10  a1 5d fb c6 69 33 60 1b  eddsa_sig_r
00000040  d8 93 53 28 2e df 91 0a  fb d1 59 5f fe 52 78 9f
00000050  46 cc c3 fe e6
00000055                 01 00 00  6d b8 e1 70 78 1d ac c0  <--- here
00000060  41 07 57 b7 a2 e3 e7 93  3b 9b 41 1e 05 bb 0a 82
00000070  16 6a 9c 4e 88 80 06

MPI encoding is "two-octet scalar that is the length of the MPI in bits 
followed by a string of octets that contain the actual integer." [1]

And since "The length field of an MPI describes the length starting from 
its most significant non-zero bit" the initial "00" byte seems redundant 
(and should not be included in the length value).

The MPI section of 4880bis even has an example that shows that zeros 
should not be taken into account:

"Thus, the MPI [00 02 01] is not formed correctly.  It should be [00 01 
01]." [1].

The rest has a length of 248 bits:

6d b8 e1 70 78 1d ac c0 41 07 57 b7 a2 e3 e7 93 3b 9b 41 1e 05 bb 0a 82 
16 6a 9c 4e 88 80 06 (31 bytes * 8 = 248 bits)

I'm also not sure how to could bits in the first byte. Since 6d is 0110 
1101 in binary maybe it should count as 7 not 8 (since the most 
significant bit is cleared)?

Is there an explanation to this behavior? I'm wondering why did GnuPG 
generate such a signature and whether or not this is conformant with the 
standard that is in development.

Thank you for your time!

Kind regards,
Wiktor

[0]: 
https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-rfc4880bis-10#section-5.2.3

[1]: 
https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-rfc4880bis-10#section-3.2