I'm using mbed TLS for ECDH key agreement using Curve25519. The private and public keys are stored and transmitted as Hex strings as easily generated with mbed TLS. Those strings are big-endian. This worked quite fine so far.
Now someone tried to create key-pairs using OpenSSL
openssl genpkey -algorithm X25519 -out priv.pem openssl pkey -in priv.pem -pubout -out pub.pem
and extracted the keys directly from there to Hex strings. So just copying the key bytes using an ASN.1 viewer. We were of the impression that this should work flawlessly, as I2OSP defines big-endian for key encoding.
Obviously, it didn't work but we need to reverse the byte order in the string to be able to parse a valid key pair.
I'm tended to believe that OpenSSL does this correctly, but started to dig into the RFCs to find proof and some clarification, why this should be different for X25519 (and probably X448) to the key for RSA or the other EC curves (secp...)
how a private key is encoded is left for the document describing the algorithm itself
but also refers to Asymmetric Key Packages which again refers to the document that defines the algorithm. While RFC5915 for ECPrivateKey defines a big-endian byte order (I2OSP), RFC7748 and RFC8031 both only mention little-endian byte order for the formatting of the keys. - draft-ietf-curdle-pkix-10
Now, this somehow confirms to me, that OpenSSL is right, but I'm still missing the reason to why one should not just use network-order as done by every other algorithm out their, but the direct opposite.
Any thoughts and further information on that?