What were you trying to do that didn't work?

GnuTLS isn't using the
https://github.com/lamps-wg/dilithium-certificates/blob/174db1bced8cbb50c20fdea2b0fdf980b98d1b54/draft-ietf-lamps-dilithium-certificates.md format (CHOICE from seed / expanded / both)

What is the impact of this issue to you?

Mild headache with a dash of frustration on how many ML-DSA formats are there.

Please provide the package NVR for which the bug is seen:

gnutls-3.8.9-9.el10, gnutls-3.8.9-2.fc41 and, surprisingly enough, upstream gnutls after https://gitlab.com/gnutls/gnutls/-/commit/69cf4fb19 as well. the updated version=1 ASN.1 serialization is happening, but it's not what untimately goes into the private key file.

How reproducible is this bug?:

reliably

Steps to reproduce

1. certtool --generate-privkey --key-type mldsa44 --outfile /tmp/mldsa.pem

Expected results

    0:d=0  hl=4 l=3896 cons: SEQUENCE
    4:d=1  hl=2 l=   1 prim: INTEGER           :00
    7:d=1  hl=2 l=  11 cons: SEQUENCE
    9:d=2  hl=2 l=   9 prim: OBJECT            :2.16.840.1.101.3.4.3.17
   20:d=1  hl=4 l=3876 prim: OCTET STRING      [both seed and expanded key in a SEQUENCE?]

I'd expect gnutls to abide by one of the key formats described above, likely the 'both' one + be capable of reading all three of them. + maybe also the current one for compatibility

Actual results

    0:d=0  hl=4 l=3896 cons: SEQUENCE
    4:d=1  hl=2 l=   1 prim: INTEGER           :00
    7:d=1  hl=2 l=  11 cons: SEQUENCE
    9:d=2  hl=2 l=   9 prim: OBJECT            :2.16.840.1.101.3.4.3.17
   20:d=1  hl=4 l=3876 prim: OCTET STRING      [a concatenation of private and public key, parsed using known offset]

I presume that the resulting private key will not be widely interoperable.