From: "Gerd Hoffmann" <kraxel@redhat.com>
To: "Yao, Jiewen" <jiewen.yao@intel.com>
Cc: "Li, Yi1" <yi1.li@intel.com>,
"devel@edk2.groups.io" <devel@edk2.groups.io>,
"Kovvuri, Vineel" <vineelko@microsoft.com>,
"Luo, Heng" <heng.luo@intel.com>
Subject: Re: [edk2-devel] [PATCH 1/2] Reconfigure OpensslLib to add elliptic curve chipher algorithms
Date: Wed, 2 Mar 2022 08:42:02 +0100 [thread overview]
Message-ID: <20220302074202.xtjfu4yqi3vxm7ec@sirius.home.kraxel.org> (raw)
In-Reply-To: <MW4PR11MB5872069BA15060123FB6AA368C039@MW4PR11MB5872.namprd11.prod.outlook.com>
On Wed, Mar 02, 2022 at 06:59:48AM +0000, Yao, Jiewen wrote:
> I think another option to pursue is to how to control the openssl configuration from module or platform level.
>
> E.g. what if platform-A has enough size and wants to use ECC, while platform-B has size constrain and wants to disable ECC ?
>
> We can let platform choose if ECC is needed or not? I hope so.
Not so easy. Would require to put the way openssl is integrated upside
down. Today openssl is configured and the results (header files etc)
are committed to the repo, so the openssl config is the same for
everybody.
Also I expect there is no way around ecc long-term. WPA3 was mentioned
elsewhere in the thread. For TLS it will most likely be a requirement
too at some point in the future. With TLS 1.2 it is possible to choose
ciphers not requiring ECC, for TLS 1.3 ECC is mandatory though.
So I doubt making ECC optional is worth the trouble.
take care,
Gerd
next prev parent reply other threads:[~2022-03-02 11:21 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-12 5:38 [PATCH 1/2] Reconfigure OpensslLib to add elliptic curve chipher algorithms Vineel Kovvuri
2021-10-12 5:38 ` [PATCH 2/2] Allow wildcards in hostname Vineel Kovvuri
2021-10-13 2:50 ` Yao, Jiewen
2021-10-13 2:45 ` [PATCH 1/2] Reconfigure OpensslLib to add elliptic curve chipher algorithms Yao, Jiewen
2021-10-17 2:49 ` Yao, Jiewen
2021-10-18 20:06 ` vineelko
2021-11-03 0:37 ` Yao, Jiewen
2021-11-03 8:34 ` Vineel Kovvuri
2021-11-08 22:29 ` [edk2-devel] " Vineel Kovvuri
2021-11-09 8:06 ` Yao, Jiewen
2021-11-09 8:58 ` Gerd Hoffmann
2021-11-10 16:18 ` Vineel Kovvuri
2021-11-11 13:05 ` Gerd Hoffmann
2021-11-11 13:26 ` Yao, Jiewen
2021-11-18 18:40 ` Vineel Kovvuri
2022-02-23 2:32 ` yi1 li
2022-02-23 2:46 ` Vineel Kovvuri
2022-02-23 2:54 ` yi1 li
2022-02-24 6:51 ` Vineel Kovvuri
2022-02-24 8:20 ` yi1 li
2022-02-25 17:51 ` Vineel Kovvuri
2022-02-26 15:54 ` yi1 li
2022-02-28 8:24 ` yi1 li
2022-03-01 14:04 ` Gerd Hoffmann
2022-03-01 17:38 ` Sean
2022-03-02 4:23 ` yi1 li
2022-03-02 6:59 ` Yao, Jiewen
2022-03-02 7:42 ` Gerd Hoffmann [this message]
2022-03-02 11:56 ` Yao, Jiewen
2022-03-03 8:43 ` yi1 li
2022-03-03 10:05 ` Yao, Jiewen
2022-03-04 2:15 ` Vineel Kovvuri
2022-03-02 7:58 ` Gerd Hoffmann
2022-03-03 6:30 ` Vineel Kovvuri
2022-03-03 6:37 ` Vineel Kovvuri
2021-11-09 8:55 ` Gerd Hoffmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220302074202.xtjfu4yqi3vxm7ec@sirius.home.kraxel.org \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox