|
All,
In PKCS#11 3.0 - 2.3.5 Edwards Elliptic curve public key objects, CKA_EC_POINT is defined as "DER-encoding of the b-bit public
key value in little endian order as defined in RFC 8032".
Per PKCS11 3.1 Work Items https://wiki.oasis-open.org/pkcs11/3.1WorkItems ,
section PKCS11 3.1 Action Items item #9, encoding of Edwards keys was discussed in May 2020, see meeting minutes https://wiki.oasis-open.org/pkcs11/Meetingminutes/Minutes13052020 .
A new action item #10 was created for Bob to check encoding in NSS. In July 2020, Bob ânoted that NSS is sending a DER wrapped EC point unless an alternate variable has been set (in which case it get's changed accordingly). It should be wrapped.â See meeting
minutes https://wiki.oasis-open.org/pkcs11/Meetingminutes/Minutes22072020 .
Based on this finding, the definition for Edwards public keys was updated in PKCS#11 3.1 Working Draft 01 https://www.oasis-open.org/apps/org/workgroup/pkcs11/document.php?document_id=67981 (uploaded
Nov 17, 2020) section 2.3.5 to the following: âDER-encoded octet value wrapped inside a DER-octet header of the b-bit public key value in little endian order as defined in RFC 8032â.
In August/September 2021, we did again have emails and discussions about encoding of Edwards keys. In our meeting dd. September
29, 2021, this topic was discussed., see Meeting Minutes https://wiki.oasis-open.org/pkcs11/Meetingminutes/Minutes29092021 . As follow-up Tony submitted the âProposed item #13
resolution markupâ https://www.oasis-open.org/apps/org/workgroup/pkcs11/document.php?document_id=69159 and PKCS#11 3.1 Working Draft 06 https://www.oasis-open.org/apps/org/workgroup/pkcs11/document.php?document_id=69175 (uploaded
Oct 12 and 14, 2021, respectively). The definition was updated (now section 6.3.5) to âPublic key bytes in little endian order as defined in RFC 8032â, i.e. the DER encoding has been removed. This is the wording that made it into the Committee Specification
and Standard 3.1.
In this meeting dd. September 29, 2021, we already discussed the need for a PKCS#11 3.0 Errata that covers the encoding of Edwards
keys. This Errata document has been postponed as long as the new PKCS#11 3.1 standard had not been signed off.
It looks to me that we should solve this discrepancy between 3.0 and 3.1 standards by issuing such 3.0 Errata document, and by
this make clear that the encoding should be as specified in PKCS#11 3.1 standard.
@Tony, Tim, Jonathan, as you are explicitly mentioned in these meeting minutes of September 2021, please review my recap and confirm
or correct.
Best regards,
Dieter
From: pkcs11@lists.oasis-open.org
pkcs11@lists.oasis-open.org On Behalf Of Greg Scott
Sent: Friday, September 15, 2023 3:05 AM
To: pkcs11@lists.oasis-open.org
Subject: [pkcs11] 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/
|