OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Fwd: [pkcs11-comment] Conflicting definitions of Edwards curve keypairs in 3.0 and 3.1...


Valerie has picked up a message on the comments list that I seem to have missed. 

Must check my registration on the comments lists but I think Chet said that they had been having trouble with their mailing system recently.

Regards
Greg

==
Greg Scott
E: greg.scott@cryptsoft.com
M: +61 406 255 166


Begin forwarded message:

From: Vesa JÃÃskelÃinen <vesa.jaaskelainen@vaisala.com>
Subject: [pkcs11-comment] Conflicting definitions of Edwards curve keypairs in 3.0 and 3.1...
Date: September 4, 2023 at 2:47:08 PM PDT
To: pkcs11-comment@lists.oasis-open.org


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://flagged.apple.com:443/proxy?t2=DG3f3i4Rv0&o=aHR0cHM6Ly9kb2NzLm9hc2lzLW9wZW4ub3JnL3BrY3MxMS9wa2NzMTEtY3Vyci92My4wL29zL3BrY3MxMS1jdXJyLXYzLjAtb3MuaHRtbCNfVG9jMzAwNjExODI=&emid=67a4f51c-2c1d-466e-b7bf-13e19ff506d1&c=11

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://flagged.apple.com:443/proxy?t2=Dc9F7L2GS0&o=aHR0cHM6Ly9kb2NzLm9hc2lzLW9wZW4ub3JnL3BrY3MxMS9wa2NzMTEtc3BlYy92My4xL29zL3BrY3MxMS1zcGVjLXYzLjEtb3MuaHRtbCNfVG9jMTExMjAzNDIw&emid=67a4f51c-2c1d-466e-b7bf-13e19ff506d1&c=11

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




--
This publicly archived list offers a means to provide input to the
OASIS PKCS 11 TC.

In order to verify user consent to the Feedback
License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe:
pkcs11-comment-subscribe@lists.oasis-open.org
Unsubscribe:
pkcs11-comment-unsubscribe@lists.oasis-open.org
List help: pkcs11-comment-help@lists.oasis-open.org
List archive: https://flagged.apple.com:443/proxy?t2=DG7a7R7EW4&o=aHR0cDovL2xpc3RzLm9hc2lzLW9wZW4ub3JnL2FyY2hpdmVzL3BrY3MxMS1jb21tZW50&emid=67a4f51c-2c1d-466e-b7bf-13e19ff506d1&c=11/
Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
List
Guidelines:
https://flagged.apple.com:443/proxy?t2=Dr3U8m9km3&o=aHR0cDovL3d3dy5vYXNpcy1vcGVuLm9yZy9tYWlsbGlzdHMvZ3VpZGVsaW5lcy5waHA=&emid=67a4f51c-2c1d-466e-b7bf-13e19ff506d1&c=11
Committee:
https://flagged.apple.com:443/proxy?t2=DQ3a9r7Mb1&o=aHR0cDovL3d3dy5vYXNpcy1vcGVuLm9yZy9jb21taXR0ZWVzL3BrY3MxMQ==&emid=67a4f51c-2c1d-466e-b7bf-13e19ff506d1&c=11
Join OASIS: https://flagged.apple.com:443/proxy?t2=DH3x2n3qr1&o=aHR0cDovL3d3dy5vYXNpcy1vcGVuLm9yZy9qb2lu&emid=67a4f51c-2c1d-466e-b7bf-13e19ff506d1&c=11/



Attachment: smime.p7s
Description: S/MIME cryptographic signature



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]