Messages in this thread Patch in this message | | | Date | Wed, 21 Apr 2021 14:58:05 +0200 | From | Jessica Yu <> | Subject | Re: [PATCH v2 2/2] certs: Add support for using elliptic curve keys for signing modules |
| |
+++ Stefan Berger [21/04/21 08:54 -0400]: > >On 4/21/21 8:52 AM, Jessica Yu wrote: >>+++ Stefan Berger [20/04/21 17:02 -0400]: >>> >>>On 4/20/21 10:03 AM, Jessica Yu wrote: >>>>+++ Stefan Berger [08/04/21 11:24 -0400]: >>>>> >>>>>diff --git a/crypto/asymmetric_keys/pkcs7_parser.c >>>>>b/crypto/asymmetric_keys/pkcs7_parser.c >>>>>index 967329e0a07b..2546ec6a0505 100644 >>>>>--- a/crypto/asymmetric_keys/pkcs7_parser.c >>>>>+++ b/crypto/asymmetric_keys/pkcs7_parser.c >>>>>@@ -269,6 +269,10 @@ int pkcs7_sig_note_pkey_algo(void >>>>>*context, size_t hdrlen, >>>>> ctx->sinfo->sig->pkey_algo = "rsa"; >>>>> ctx->sinfo->sig->encoding = "pkcs1"; >>>>> break; >>>>>+ case OID_id_ecdsa_with_sha256: >>>>>+ ctx->sinfo->sig->pkey_algo = "ecdsa"; >>>>>+ ctx->sinfo->sig->encoding = "x962"; >>>>>+ break; >>>> >>>>Hi Stefan, >>>> >>>>Does CONFIG_MODULE_SIG_KEY_TYPE_ECDSA have a dependency on >>>>MODULE_SIG_SHA256? >>> >>>You are right, per the code above it does have a dependency on >>>SHA256. ECDSA is using NIST p384 (secp384r1) for signing and per >>>my tests it can be paired with all the sha hashes once the code >>>above is extended. Now when it comes to module signing, should we >>>pair it with a particular hash? I am not currently aware of a >>>guidance document on this but sha256 and sha384 seem to be good >>>choices these days, so maybe selecting ECDSA module signing should >>>have a 'depends on' on these? >> >>Yeah, I would tack on the 'depends on' until the code above has been >>extended to cover more sha hashes - because currently if someone >>builds and signs a bunch of modules with an ECDSA key, they will fail >>to load if they picked something other than sha256. I am unfortunately >>not knowledgeable enough to suggest an official guideline on choice of >>hash, but for now it is reasonable to have a 'depends on' for which >>hashes the code currently supports, so that users don't run into >>module loading rejection issues. > > >I was going to repost this series now with the additional OIDs >supported above and a recommendation to use sha384 in the help text >for ECDSA-signed modules, but not enforcing this but instead trusting >the user that they will choose a reasonable hash (probably >= sha256).
OK, that sounds good to me.
Thanks Stefan!
| |