gpg --export produces invalid EdDSA output - regression

[Marek Marczykowski-Górecki]

On Thu, Sep 14, 2023 at 03:49:47PM +0200, Werner Koch wrote:
> On Thu, 14 Sep 2023 14:34, Marek Marczykowski-Górecki said:
> 
> > Hmm, but the RFC seems to specify it as unsigned, not signed:
> 
> Sure - mail edit error on my part.
> 
> > Given the above, I'm not sure if that's really necessary. But even if it
> > is, it isn't "backward compatible" change, since standard
> > respecting-compliant implementation is expected to treat leading zeroes
> > as malformed.
> 
> The problem here is that this is not a number.  The MPI requirement has
> been ignored since the introduction of RFC-6637 (ECC for OpenPGP) in
> PGP, GnuPG and other implementation with support for ECC.

But GnuPG 2.2 did produced standard-compliant output, it stopped doing
so only later, no? So, where it was "ignored" that prompted changing
what output is produced?

In the discussion I see that SSH uses signed numbers there, but I don't
see how it's relevant for `gpg --export` which deals with OpenPGP
format, not SSH format.

> > My reading of the above is rather "an OpenPGP implementation that wants
> > to be compatible with GnuPG should also accept MPI that is not compliant
> > with the OpenPGP specification"... Have I missed some part of the spec?
> 
> A specification and the actual practise almost always differ. Even if
> the author of RFC-6637 also did the implementation for PGP and GnuPG.
> It is a specification bug and newer implementations need to cope with
> the reality.

While it may be desirable to have _optional_ workarounds for some
misbehaving implementation, IMO the goal should be to converge at the
specified behavior. The change we are discussing here "forces" already
compliant implementations to diverge from the spec, which is step
backward. And I'm not surprised that some projects refuse to go into
that direction...

If there is a need for this padding to workaround some bug in another
implementation (can you name specific software and version when it's
actually required?), maybe make it configurable with a switch?

> > Is this new "SOS" type described in some specification?
> 
> See
> 
> >> (see https://dev.gnupg.org/T4954)
> 
> and of course the code.

Well, issue tracker of a specific implementation is not really
specification that others should follow when implementing an IETF
standard...

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20230914/0d229e12/attachment.sig>