Hi Darren, In my mail below, I reported changes to the encoding of Edwards curves. Indeed the same updates were applied to Montgomery curves, i.e. wording about DER encoding was first changed and then removed, now stating “Public key bytes in little endian order as defined in RFC 7748”. I’m sorry, I should have noted this in my mail below. Best regards, Dieter From:
pkcs11@lists.oasis-open.org <
pkcs11@lists.oasis-open.org> On Behalf Of JOHNSON Darren Sent: Wednesday, October 25, 2023 10:36 PM To:
pkcs11@lists.oasis-open.org Subject: RE: [pkcs11] Fwd: [pkcs11-comment] Conflicting definitions of Edwards curve keypairs in 3.0 and 3.1... THALES GROUP LIMITED DISTRIBUTION to email recipients Hi, I didn’t want to respond on the call before reading the email. It sounds like the main reason/justification for removing the DER encoding was because the corresponding RFCs do not define the DER encoding. That is good enough for me. But we also added Montgomery ECC keys at the same time that we added Edwards keys, and for the same reason, we defined them using DER encoding. Should we remove the DER encoding for Montgomery keys as well? Thanks Darren Subject : RE: [pkcs11] Fwd: [pkcs11-comment] Conflicting definitions of Edwards curve keypairs in 3.0 and 3.1... From : Dieter Bong
Dieter.Bong@utimaco.com To :
pkcs11@lists.oasis-open.org pkcs11@lists.oasis-open.org Date : Thu, 19 Oct 2023 19:05:13 +0000 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/ Utimaco IS GmbH Germanusstr. 4, D.52080 Aachen, Germany, Tel: +49-241-1696-0,
www.utimaco.com Seat: Aachen – Registergericht Aachen HRB 18922 VAT ID No.: DE 815 496 496 Managing Directors: Stefan Auerbach, Martin Stamm, Hacan Tiwemark This communication is confidential. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. Please inform us immediately and destroy the email. Attachment: smime.p7s Description: S/MIME cryptographic signature