[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]