Re: [pkcs11] Edwards ECC keys in PKCS #11 3.0 again

Jakub: Not sure this is going to help as I don't fully understand the questions in your message, but in the hope that it will, I'll proceed.

First of all, 8032 is a specification for signatures using (twisted) Edwards curves Ed25519/Ed448, while 8410 covers those curves as well as the (birationally equivalent/2-isogenous) curves in Montgomery form called X448/X25519 (aka, Curve25519/Curve448 in SP800-186). The latter are only used for the key agreement schemes X25519 and X448 (RFC 7748). I'd recommend looking at NIST SP800-186 to help sort out the relationships between these curves. (https://mailarchive.ietf.org/arch/msg/cfrg/-9LEdnzVrE5RORux3Oo_oDDRksU/ is also helpful)

Once that's understood, you should also note the difference between the "key generation" ftns for EdDSA and ECDH. (Modulo some bit tweaking...) EdDSA takes a random private key octet string, hashes it, multiplies the base point by that hash value interpreted as an integer, then combines the y coordinate with a compressed x coordinate to obtain the "public key" octet string (FIPS 186-5 section 7.2). Fairly conventional.

OTOH, for X25519/X448 (i.e., ECDH with Curve25519/Curve448), all computations are based solely on x coordinates and one never really has to generate a public point; which results in a certain ambiguity about which point would have been the corresponding "public key" in a classical ECC scheme. In fact, what gets published here as a "public key" is the value of the ftn X25519(x,9) (resp., X448(x,5)) evaluated at the private key x and encoded as an octet string. (See RFC 7748 sections 5&6.)

This might be the meaning of "keys defined by RFC 8032 and RFC 8410 are incompatible" that you seek... or it might not.

The discussion here will either help or confuse you further:

Be happy to continue to try to clarify this, if you still have questions.

From: pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org> on behalf of Jakub Jelen <jjelen@redhat.com>
Sent: Tuesday, March 10, 2020 9:47 AM
To: pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org>
Subject: [pkcs11] Edwards ECC keys in PKCS #11 3.0 again

Hello all,

I made my way through the implementation of the Edwards ECC keys
support in few projects and while trying inter-operability tests among
different modules and tooles, it turned out that there are still few
bits that are not clear to me (nor for other people trying to review my
changes and the specs). Assuming this will be a common problem for
others, I believe this can be a base for 3.1/errata or some
clarification statement

1) The value of CKA_EC_POINT of CKK_EC_EDWARDS keys is described as
follows:

> DER-encoding of the b-bit public key value in little endian order as
defined in RFC 8032

But this really misses implementation details. The reference to RFC
8032 can mean that the value is encoded as "octet strings" (which would
match how the ECDSA keys are encoded). To this question, I was brought
by the following discussion in the gnutls [1], which initially
implemented the EC_POINT as raw bit string.

2) The value of CKA_EC_PARAMS can be either OID or the curve name. The
example templates show the usage of curve name version only. The
initial implementation of SoftHSM supported only OIDs, but I extended
it to support curve names and use them by default [2]. The PKCS #11 3.0
says:

> Edwards EC public keys only support the use of the curveName
selection to specify a curve name as defined in [RFC 8032] and the use
of the oID selection to specify a curve through an EdDSA algorithm as
defined in [RFC 8410].

But from my reading of both RFCs and all around and along the lines, I
was able to figure out that the RFC 8042 specifies the algorithm itself
and RFC 8410 compatible signature algorithms for PKI. But this sounds
like in contradiction with the following sentence:

> Note that keys defined by RFC 8032 and RFC 8410 are incompatible.

Did the author mean that not all of the named curves have appropriate
OIDs? Or that the applications should not attempt to make them
compatible even if they are the same curve (to my understanding)? Or
something else?

Is there one definition that should be preferred for the tools creating
keys and pkcs11 modules presenting existing keys?

[1] https://gitlab.com/gnutls/gnutls/-/merge_requests/1200
[2] https://github.com/opendnssec/SoftHSMv2/pull/526
[3] https://www.openssl.org/docs/man1.1.1/man7/Ed25519.html

Regards,
--
Jakub Jelen
Senior Software Engineer
Security Technologies
Red Hat, Inc.

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

pkcs11 message