Move low-level crypto API away for OpenSSL 3.0?

[liyi77]

Use of the low level APIs has been informally discouraged by the OpenSSL development team for a long time, such EC_KEY*, RSA*..., and more, in OpenSSL 3.0 this is made more formal. All such low level APIs have been deprecated, do we need to update our code to high-level crypto API?

I've done some research on EC and if this change is really needed, I'll try more APIs. https://github.com/liyi77/libspdm/pull/8

[jyao1]

Is this for openssl 3.0? We have POC - https://github.com/DMTF/libspdm/tree/openssl_3.0.2_eval. (backup to https://github.com/jyao1/libspdm/tree/openssl_3.0.2_eval)

If you can keep the library API as is, then I am open to change the implementation. Feel free to propose PR.

[liyi77]

Based on openssl3.0 would be better, I will do my work on this branch

[jyao1]

We need openssl 3.0.7 at least, where a high issue is fixed.

Ref: https://www.openssl.org/news/openssl-3.0-notes.html, and https://www.openssl.org/news/vulnerabilities.html

[steven-bellock]

I'd like for libspdm 3.0 to be a LTS release. OpenSSL 1.1.1 reaches end-of-life in September 2023, by which libspdm should be using OpenSSL 3.0. So it would be good for this to be available in the libspdm 3.0 release.

[jyao1]

Let's focus on openssl 3.0 enabling at first, without API change.

[jyao1]

It seems the DMTF POC branch is deleted. The POC branch can be found at https://github.com/jyao1/libspdm/tree/openssl_3.0.2_eval.

[steven-bellock]

@jyao1 has most of the algorithms enabled, but SM2 is being stubborn.