Thank you, Dieter & Darren, for digging into this!
My general concern is, correct or not, we have now introduced an incompatibility. It sounds like there are implementations now that either have the DER encoding and others that do not, and they cannot interoperate.
I usually follow the âonce published, we are stuck with itâ, unless the item is impossible to implement as described or there is a security issue.
The committee made a different choice & fixed the error in 3.1, but has not, yet, issued an errata for 3.0. At what point is it too late to issue an errata for 3.0? There are implementations out there of 3.0 (and 3.1 now coming).
I would lean towards reverting to the older definition & updating via a 3.1 errata document (quite quickly), including a note regarding backwards compatibility. Then perhaps we can look for a compatible way forward, if possible.
Valerie
On Oct 30, 2023, at 3:58âAM, JOHNSON Darren <darren.johnson@thalesgroup.com> wrote:
THALES GROUP LIMITED DISTRIBUTION to email recipients Hi Dieter, Yes, you are right. Turns out I had an older version of the spec open as well. Thanks! From: Dieter Bong <Dieter.Bong@utimaco.com>
Sent: Sunday, October 29, 2023 1:47 PM
To: JOHNSON Darren <darren.johnson@thalesgroup.com>; pkcs11@lists.oasis-open.org
Subject: RE: RE: [pkcs11] Fwd: [pkcs11-comment] Conflicting definitions of Edwards curve keypairs in 3.0 and 3.1... 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...
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". 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 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 M: +61 406 255 166 Begin forwarded message: 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
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.
|