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

[Jakub Jelen <jjelen@redhat.com>]

Hi Michael,
thank you for prompt reply.

On Wed, 2020-03-11 at 06:34 +0000, Michael Markowitz wrote:
> 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)

Right. That is as much as I already figured out. The difference between
the Curve25519 and Ed25519 keys and X25519 mechanism is already clear
to me, but thank you for sharing these additional links. They are
indeed 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.

Right, but this is something that should not bother us on the layer of
PKCS#11 layer.

> 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.

Right. So this would basically translate to X25519/X448 keys
(montgomery) are incompatible with EdDSA/Ed25519 keys (edwards), which
I thought is already obvious as they have different CKA_KEY_TYPE and
separate sections.

I find it confusing as the sentence follows directly the one talking
about the parameters specification with the reference to the same RFCs,
but it really can be as simple as you say.

In that case, lets take an example of SoftHSM (referenced in previous
email), which creates software token using OpenSSL primitives Ed25519
[1], which is described as PureEdDSA, Ed25519 algorithms [RFC8032] and
keys according to draft-ietf-curdle-pkix-04 (current RFC 8410). What
should the the value it should present in EC_PARAMS attribute?

The RFC 8032 (and example template) uses curve name "edwards25519"
(defined from RFC 7748), so this sounds like a first think to look at
and use. Additionally, the RFC 8410 specifies algorithm OID for the
same curves ("Ed25519" for PureEdDSA mode) as follows:

OBJECT IDENTIFIER ::= { 1 3 101 112 }

I assume this gives modules and applications choice which of these
encodings to use for identifying one key, while requiring them to
handle both of the values when creating/accepting the key. Do you read
it the same way?

Second question was about encoding EC_POINT. After several more
readings of the specs and referenced RFC, I am almost sure it should be
OCTET STRING as specified in RFC 8032, Section 5.1.2, but I would like
to hear an opinion from somebody else that it is their reading too.

[1] https://www.openssl.org/docs/man1.1.1/man7/Ed25519.html
[2] https://tools.ietf.org/html/rfc8032#section-5.1.2

Regards,
Jakub