Fix Notation regarding ECC key descriptions and object structures

[ehanoc]

Why

Some of the notations are incorrect in the context of elliptic curve cryptography specifically in the context of Twisted Edwards Curve form.

• Private key notation change: from d to k; because d is a throw back to RSA private key notation; k is used commonly to represent the scalar value [ECC private key]

• The crv field stated ed25519 which is a signature scheme NOT a curve, the curve is called Edwards25519

• Assuming the spec intends to hold the public key coordinate inside the private key declaration, it should be represented as y, unlike Montgomery form curves (i.e Curve25519), which use the x coordinate with a y sign bit in compressed form, the Edward's twist uses a y coordinate with an x sign bit.

References

• [Curve25519] (https://crypto.stackexchange.com/questions/72134/raw-curve25519-public-key-points)
• [Crypto Curves] (https://safecurves.cr.yp.to/equation.html)
• [Edwards Curves] (https://cryptobook.nakov.com/asymmetric-key-ciphers/elliptic-curve-cryptography-ecc#edwards-curves)

[OR13]

See also https://www.rfc-editor.org/rfc/rfc8037#appendix-A.4

[ehanoc]

Appreciate the reply @OR13

I can see how my first point wouldn't be compatible with the spec. Using d for the scalar as the pvtkey seems right then.

Although It is important to get all right, specially around 25519. I dare to say some of these specs are actually incorrect and confuse a lot of people. They might need to be revised (maybe already through Erratas?). Specially around ed22519 and the compressed form representation of it's public key. In Edwards twisted curves it's the y(255 bits) with a signed bit for x. And the spec clearly says x.

The other more minor issue is that they put ed25519 under elliptic curves, which is technically false. It's a signature scheme. Reference here https://ed25519.cr.yp.to/ from the actual author.

Any chance we can get more eyes on this?

[OR13]

I suggest you take this to CFRG IETF list or JOSE lists, this spec aims to support key formats that conform to standards.

There are a lot of non standard key formats that might be more compact / aesthetic, but that are less well adopted, and therefore less interoperable.

You might also use the multikey format, which probably aligns more with what you are expecting and is currently being standardized at W3C, in the vc-data-integrity spec.

[ehanoc]

Thanks @OR13 , i understand that you are trying to comply with the spec.

Will have a look at the vc-data-integrity spec.