Conflicting definitions of Edwards curve keypairs in 3.0 and 3.1...

[Vesa JÃÃskelÃinen <vesa.jaaskelainen@vaisala.com>]

Hi All,

While developing Edwards curve support for OP-TEE PKCS#11 Trusted 
Application we noticed that there seems to be an issue with PKCS#11 
standards 3.0 and 3.1 related to Edwards curve keypairs.


In PKCS#11 3.0 - 2.3.5 Edwards Elliptic curve public key objects:

https://docs.oasis-open.org/pkcs11/pkcs11-curr/v3.0/os/pkcs11-curr-v3.0-os.html#_Toc30061182

CKA_EC_POINT is being defined as "DER-encoding of the b-bit public key 
value in little endian order as defined in RFC 8032".

And private key's CKA_VALUE as "b-bit private key value in little endian 
order as defined in RFC 8032".


In PKCS#11 3.1 - 6.3.5 Edwards Elliptic Curve public key objects:

https://docs.oasis-open.org/pkcs11/pkcs11-spec/v3.1/os/pkcs11-spec-v3.1-os.html#_Toc111203420

CKA_EC_POINT is being defined as "Public key bytes in little endian 
order as defined in RFC 8032".

And private key's CKA_VALUE as "Private key bytes in little endian order 
as defined in RFC 8032".


We went for path of 3.1 without noticing that there was difference. Now 
when we were starting to test it out against other tools (in example 
OpenSC's pkcs11-tool) we noticed that it did not work as expected.

As these are long term storage in our implementation spanning several 
years in use we seek for advice:

a) as there is now compatibility issue what is the correct choice of action:

ÂÂ - stick with 3.1 standard and try to fix the other tooling? Will 
there be errata for 3.0 then to support the change requests?

ÂÂ - go back to 3.0 standard way and will there be errata for 3.1?

b) how can user of the API know what to expect as input/output?

c) how can implementor of the API to do the right thing?


Thanks,
Vesa JÃÃskelÃinen