[gnutls-devel] GnuTLS | Add support for loading Ed25519 keys from PKCS#11 and using them (!1200)
Development of GNU's TLS library
gnutls-devel at lists.gnutls.org
Mon Mar 9 08:37:51 CET 2020
Merge request https://gitlab.com/gnutls/gnutls/-/merge_requests/1200 was reviewed by Jakub Jelen
--
Jakub Jelen commented on a discussion on lib/pkcs11_write.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1200#note_301564436
> - a[*a_val].value_len = pubkey->params.raw_pub.size;
> + a[*a_val].value = ecpoint.data;
> + a[*a_val].value_len = ecpoint.size;
The change is intentional, but after reading the specifications, not sure if completely correct. The current implementation is most probably wrong as it uses only the raw bytes of public key. The octet string is what is used in ECDSA keys in PKCS#11 and what is used in SoftHSM at this moment. The RFC 8410 on the other hand refers to public key as BIT STRING.
--
Jakub Jelen commented on a discussion on lib/pkcs11_write.c: https://gitlab.com/gnutls/gnutls/-/merge_requests/1200#note_301564438
>
> + /* XXX This is wrong -- we need encode the curve name
> + * not OID according to the last PKCS #11 3.0 draft */
My reading is that RFC 8410 defines `id-Ed25519`, which should be referenced by OID, while RFC 8032 defines what we call edwards25519 keys (and few others), but I might be reading this wrong and we could use the OIDs too.
The softhsm now supports both named curves and OIDs:
https://github.com/opendnssec/SoftHSMv2/pull/526
--
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/merge_requests/1200
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20200309/e36c4cae/attachment.html>
More information about the Gnutls-devel
mailing list