OASIS PKCS 11 TC

Hi folks, At our last meeting I undertook to re-post the last round of comments from Darren Johnson. Please find them below: 1. Was it intentional not to include CKF_EC_CURVENAME in Table 34? Although we mention this flag later on in the text, it's neither defined in the header files nor used anywhere else. [DJ] No, I don t think it was intentionally left out. The last three versions of the proposal included CKF_EC_CURVENAME. I think we just missed it during the editorial phase. 2. RFC 8410 now defines four OIDs for Ed25519, Ed448, X25519 and X448. Note that this not only denotes the curve but also the algorithm. This was a conscious decision (see e.g. https://mailarchive.ietf.org/arch/msg/curdle/OL3Y4ohwleOukV8CMkE9kgrFPZg ). Our WD08 refers to a curve name as defined in RFC 8032 and gives as example Edwards25519 . (The same holds for Montgomery curves, but no example is given.) Thus, it does not make the distinction between the different algorithms. Instead, the CKM_EDDSA mechanism gets a parameter that specifies the algorithm. 2a. Shall we keep this approach? 2b. Shall be also allow to use the four OIDs defined in RFC 8410 to identify a curve? Then, the mechanism would be restricted to the Pure version and no mechanism parameter is allowed. These OIDs are more inline with my other proposal where key+params+alg are It is odd, the OID owners do have OIDs for the pre-hashed variants. But for some reason they did not include them in RFC8410. 3. There is the Extended Triple Diffie-Hellman algorithm working on Montgomery curves, but I'm missing the normal ECDH mechanism working on curve25519/curve448 as described in RFC 7748 section 6. Or shall CKM_ECDH1_DERIVE with KDF_NULL and empty sharedData be used? Or better introduce a new mechanism? [DJ] In the proposal, a small table was added to section 2.3.17 and 2.3.18, which defined the key types supported for CKM_ECDH1_DERIVE and CKM_ECDH1_COFACTOR_DERIVE. The table listed both CKK_EC and CKK_EC_MONTGOMERY. The intent was that those tables would show that the existing ECDH mechanisms could be used with the Montgomery curves. Maybe we need more information than just the tables? Or a new mechanism as you suggest? Those tables were not added to the working draft. 4. For the non-prehashed EdDSA variants the message needs to be processed twice by the function. Therefore, they are single-shot and cannot be used with update/final. Shall we mention this explicitly and agree on an error code? [DJ] Is single-part vs multi-part something the spec should be dictating? I know it does today. But for the most part, the question of single-part vs multi-part really comes down to a specific implementations complexity and resource constraints. Would it make sense to introduce some mechanism flags to let vendors define if each mechanism supports single-part or multi-part (or both) calling conventions? Best Regards, -Tony Cox

Tony, all,
 
These comments have all been solved since they were about the Edwards/Montgomery curves and we discussed this during the F2F. The result is included in latest base and mech working draft
see upload mails of March 26 ( https://lists.oasis-open.org/archives/pkcs11/201903/msg00014.html
and
https://lists.oasis-open.org/archives/pkcs11/201903/msg00015.html ). No comments so far.

 
What has not been discussed are Darren s comments to the
mechanisms specific (upload mail
https://lists.oasis-open.org/archives/pkcs11/201902/msg00001.html ). There was a short discussion between Darren and myself ( https://lists.oasis-open.org/archives/pkcs11/201902/msg00006.html
and
https://lists.oasis-open.org/archives/pkcs11/201902/msg00007.html ) but no TC agreement.
 
Regards,
Daniel
 


From: pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org>
On Behalf Of Tony Cox
Sent: Mittwoch, 10. April 2019 07:41
To: pkcs11@lists.oasis-open.org
Subject: [pkcs11] Comments from Darren J (repost)


 
Hi folks,
At our last meeting I undertook to re-post the last round of comments from Darren Johnson. Please find them below:
 
1. Was it intentional not to include CKF_EC_CURVENAME in Table 34? Although we mention this flag later on in the text, it's neither defined in the header files nor used anywhere
else.
 [DJ] No, I don t think it was intentionally left out.  The last three versions of the proposal included CKF_EC_CURVENAME.  I think we just missed it
during the editorial phase.
 
2. RFC 8410 now defines four OIDs for Ed25519, Ed448, X25519 and X448. Note that this not only denotes the curve but also the algorithm. This was a conscious decision (see e.g.

https://mailarchive.ietf.org/arch/msg/curdle/OL3Y4ohwleOukV8CMkE9kgrFPZg ). Our WD08 refers to "a curve name as defined in RFC 8032" and gives as example "Edwards25519". (The same holds for Montgomery curves, but no example is given.) Thus, it does not make
the distinction between the different algorithms. Instead, the CKM_EDDSA mechanism gets a parameter that specifies the algorithm.
2a. Shall we keep this approach?
2b. Shall be also allow to use the four OIDs defined in RFC 8410 to identify a curve? Then, the mechanism would be restricted to the "Pure" version and no mechanism parameter is
allowed.
  These OIDs are more inline with my other proposal where key+params+alg are
It is odd, the OID owners do have OIDs for the pre-hashed variants.  But for some reason they did not include them in RFC8410.
 
3. There is the Extended Triple Diffie-Hellman algorithm working on Montgomery curves, but I'm missing the "normal" ECDH mechanism working on curve25519/curve448 as described in
RFC 7748 section 6. Or shall CKM_ECDH1_DERIVE with KDF_NULL and empty sharedData be used? Or better introduce a new mechanism?
[DJ] In the proposal, a small table was added to section 2.3.17 and 2.3.18, which defined the key types supported for CKM_ECDH1_DERIVE and CKM_ECDH1_COFACTOR_DERIVE. 
The table listed both CKK_EC and CKK_EC_MONTGOMERY.  The intent was that those tables would show that the existing ECDH mechanisms could be used with the Montgomery curves.  Maybe we need more information than just the tables?  Or a new mechanism as you suggest?
Those tables were not added to the working draft.
 
4. For the non-prehashed EdDSA variants the message needs to be processed twice by the function. Therefore,
they are single-shot and cannot be used with update/final. Shall we mention this explicitly and agree on an error code?
[DJ] Is single-part vs multi-part something the spec should be dictating?  I know it does today.  But for the most part, the question of single-part vs multi-part really comes down to a specific implementations
complexity and resource constraints.  Would it make sense to introduce some mechanism flags to let vendors define if each mechanism supports single-part or multi-part (or both) calling conventions?

Best Regards,
-Tony Cox




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
Managementboard: Stefan Auerbach (Chairman) CEO, Malte Pollmann CSO, Dr. Frank J. Nellissen CFO

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.

On 04/09/2019 10:40 PM, Tony Cox wrote: Hi folks, At our last meeting I undertook to re-post the last round of comments from Darren Johnson. Please find them below: 1. Was it intentional not to include CKF_EC_CURVENAME in Table 34? Although we mention this flag later on in the text, it's neither defined in the header files nor used anywhere else. [DJ] No, I don t think it was intentionally left out. The last three versions of the proposal included CKF_EC_CURVENAME. I think we just missed it during the editorial phase. CKF_EC_CURVENAME replaces CKF_EC_OID which was deprecated. The former is in the identifiers database and the latter is in the aliases database (identifiers that we've renamed, but kept the old definition I have a proposal in the 2. RFC 8410 now defines four OIDs for Ed25519, Ed448, X25519 and X448. Note that this not only denotes the curve but also the algorithm. This was a conscious decision (see e.g. https://mailarchive.ietf.org/arch/msg/curdle/OL3Y4ohwleOukV8CMkE9kgrFPZg ). Our WD08 refers to a curve name as defined in RFC 8032 and gives as example Edwards25519 . (The same holds for Montgomery curves, but no example is given.) Thus, it does not make the distinction between the different algorithms. Instead, the CKM_EDDSA mechanism gets a parameter that specifies the algorithm. 2a. Shall we keep this approach? 2b. Shall be also allow to use the four OIDs defined in RFC 8410 to identify a curve? Then, the mechanism would be restricted to the Pure version and no mechanism parameter is allowed. These OIDs are more inline with my other proposal where key+params+alg are It is odd, the OID owners do have OIDs for the pre-hashed variants. But for some reason they did not include them in RFC8410. So IIRC the only oids that matter in PKCS #11 is the key+params oids. Applications have to map signature oids from their ANS.1 encoded signatures and map them to the appropriate mechanisms. The only exception is if the oid is imbedded in the signature (as it is in RSA). I don't think that's the case with EDDSA. I think the 4 oids that we are talking about here are the key_params oids, so Darren's question is still relevant. It seems 2a would be consistent with restricting keys to particular functions (the generated key was specifically EDDSA). 2b would be more flexible (from the application perspective). Restricted functionality could still be controlled with the existing CKA_SIGN/CKA_DERIVE flags on the key itself. So I'm OK with either one here. 3. There is the Extended Triple Diffie-Hellman algorithm working on Montgomery curves, but I'm missing the normal ECDH mechanism working on curve25519/curve448 as described in RFC 7748 section 6. Or shall CKM_ECDH1_DERIVE with KDF_NULL and empty sharedData be used? Or better introduce a new mechanism? [DJ] In the proposal, a small table was added to section 2.3.17 and 2.3.18, which defined the key types supported for CKM_ECDH1_DERIVE and CKM_ECDH1_COFACTOR_DERIVE. The table listed both CKK_EC and CKK_EC_MONTGOMERY. The intent was that those tables would show that the existing ECDH mechanisms could be used with the Montgomery curves. Maybe we need more information than just the tables? Or a new mechanism as you suggest? Those tables were not added to the working draft. We should probably include the table, or text that mirrors the table. The use of CKK_EC_MONTGOMERY with EC_DH seems like the right semantic to me (we are already doing that in our code). 4. For the non-prehashed EdDSA variants the message needs to be processed twice by the function. Therefore, they are single-shot and cannot be used with update/final. Shall we mention this explicitly and agree on an error code? [DJ] Is single-part vs multi-part something the spec should be dictating? I know it does today. But for the most part, the question of single-part vs multi-part really comes down to a specific implementations complexity and resource constraints. Would it make sense to introduce some mechanism flags to let vendors define if each mechanism supports single-part or multi-part (or both) calling conventions? I think in cases where multi-part does not make sense or can't be implemented, we should probably call that out in the spec. The module implementer would know it had to be single-part, but the application may not. It's pretty common for the raw asymmetric sign/verify code to be single-part only, so EdDSA wouldn't be unique. bob Best Regards, -Tony Cox

Bob, all, See my mail od Apr 10. This has all been already resolved. There is another mail/document of Darren that needs attention. All information is in my mail... Thanks  Daniel  Von meinem Samsung Galaxy Smartphone gesendet. -------- Ursprüngliche Nachricht -------- Von: Robert Relyea <rrelyea@REDHAT.COM> Datum: 18.04.19 18:25 (GMT+01:00) An: pkcs11@lists.oasis-open.org Betreff: Re: [pkcs11] Comments from Darren J (repost) On 04/09/2019 10:40 PM, Tony Cox wrote: Hi folks, At our last meeting I undertook to re-post the last round of comments from Darren Johnson. Please find them below: 1. Was it intentional not to include CKF_EC_CURVENAME in Table 34? Although we mention this flag later on in the text, it's neither defined in the header files nor used anywhere else.  [DJ] No, I don’t think it was intentionally left out.  The last three versions of the proposal included CKF_EC_CURVENAME.  I think we just missed it during the editorial phase. CKF_EC_CURVENAME replaces CKF_EC_OID which was deprecated. The former is in the identifiers database and the latter is in the aliases database (identifiers that we've renamed, but kept the old definition I have a proposal in the   2. RFC 8410 now defines four OIDs for Ed25519, Ed448, X25519 and X448. Note that this not only denotes the curve but also the algorithm. This was a conscious decision (see e.g. https://mailarchive.ietf.org/arch/msg/curdle/OL3Y4ohwleOukV8CMkE9kgrFPZg ). Our WD08 refers to "a curve name as defined in RFC 8032" and gives as example "Edwards25519". (The same holds for Montgomery curves, but no example is given.) Thus, it does not make the distinction between the different algorithms. Instead, the CKM_EDDSA mechanism gets a parameter that specifies the algorithm. 2a. Shall we keep this approach? 2b. Shall be also allow to use the four OIDs defined in RFC 8410 to identify a curve? Then, the mechanism would be restricted to the "Pure" version and no mechanism parameter is allowed.   These OIDs are more inline with my other proposal where key+params+alg are It is odd, the OID owners do have OIDs for the pre-hashed variants.  But for some reason they did not include them in RFC8410. So IIRC the only oids that matter in PKCS #11 is the key+params oids. Applications have to map signature oids from their ANS.1 encoded signatures and map them to the appropriate mechanisms. The only exception is if the oid is imbedded in the signature (as it is in RSA). I don't think that's the case with EDDSA. I think the 4 oids that we are talking about here are the key_params oids, so Darren's question is still relevant.  It seems 2a would be consistent with restricting keys to particular functions (the generated key was specifically EDDSA). 2b would be more flexible (from the application perspective). Restricted functionality could still be controlled with the existing CKA_SIGN/CKA_DERIVE flags on the key itself. So I'm OK with either one here.   3. There is the Extended Triple Diffie-Hellman algorithm working on Montgomery curves, but I'm missing the "normal" ECDH mechanism working on curve25519/curve448 as described in RFC 7748 section 6. Or shall CKM_ECDH1_DERIVE with KDF_NULL and empty sharedData be used? Or better introduce a new mechanism? [DJ] In the proposal, a small table was added to section 2.3.17 and 2.3.18, which defined the key types supported for CKM_ECDH1_DERIVE and CKM_ECDH1_COFACTOR_DERIVE.  The table listed both CKK_EC and CKK_EC_MONTGOMERY.  The intent was that those tables would show that the existing ECDH mechanisms could be used with the Montgomery curves.  Maybe we need more information than just the tables?  Or a new mechanism as you suggest? Those tables were not added to the working draft. We should probably include the table, or text that mirrors the table. The  use of CKK_EC_MONTGOMERY with EC_DH seems like the right semantic to me (we are already doing that in our code).   4. For the non-prehashed EdDSA variants the message needs to be processed twice by the function. Therefore, they are single-shot and cannot be used with update/final. Shall we mention this explicitly and agree on an error code? [DJ] Is single-part vs multi-part something the spec should be dictating?  I know it does today.  But for the most part, the question of single-part vs multi-part really comes down to a specific implementations complexity and resource constraints.  Would it make sense to introduce some mechanism flags to let vendors define if each mechanism supports single-part or multi-part (or both) calling conventions? I think in cases where multi-part does not make sense or can't be implemented, we should probably call that out in the spec. The module implementer would know it had to be single-part, but the application may not. It's pretty common for the raw asymmetric sign/verify code to be single-part only, so EdDSA wouldn't be unique. bob Best Regards, -Tony Cox 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 Managementboard: Stefan Auerbach (Chairman) CEO, Malte Pollmann CSO, Dr. Frank J. Nellissen CFO 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.