OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]