But in Edwards curves, unlike Montgomery (Curve25519) shouldn't be Y
with a signed bit for X instead?
Yes
In RFC8037, they say that the public key in its compressed form (32
bytes) should be represented by X
They call it x in the JSON representation, which I agree is confusing. However, I've checked their example private key 9d61b19deffd5a60ba844af492ec2cc44449c5697b326919703bac031cae7f60. If you hash that with SHA-512, clamp it, scalar multiply it with the base point, extract the y co-ordinate of the resulting point, and apply the sign bit if necessary, the answer is identical to the hex public key example they list in the appendix.
I suspect their reasoning is that when x and y are specified, they really are co-ordinates of an EC point. However, when using 'point compression' to represent the point in a single 32-byte sequence, strictly speaking it's no longer a y co-ordinate because of the sign-bit manipulation. So I'm guessing they just decided to always place a compressed point representation in the x field and leave the y field empty (regardless of which of the two co-ordinates the compressed point representation was derived from).
Another thing that's odd is that on both RFC and IANA they put ed25519
in the elliptic curve section. But technically it's a signing scheme
not a curve?
People commonly refer to both the signature scheme and to the curve itself as Ed25519. Monero, for example, uses the Ed25519 curve but not the Ed25519 signature scheme.
