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