Hello
I would like to give a proposal for the openssl 1.1 replacement in EDKII community.

[Problem Statement]
Openssl 1.1 is about to EOL at September, 2023. We need find replacement.

Bugzilla:
1. Openssl3.0: https://bugzilla.tianocore.org/show_bug.cgi?id=3466
2. MbedTls: https://bugzilla.tianocore.org/show_bug.cgi?id=4177

[POC result]
1. The natural successor is Openssl 3.0.
However, it brings size issue according to the POC evaluation - https://edk2.groups.io/g/devel/topic/87479913.
The concern is that: The size of flash is fixed. If we naïve replace it directly, the existing platforms may be broken immediately.

2. The alternative is MbedTls, which is much smaller.
However, there is feature gap, e.g. PKCS7 is not there.

3. At same time, we evaluated other crypto library.
A. Intel-IPP: https://software.intel.com/en-us/intel-ipp , https://github.com/intel/ipp-crypto (Apache license) - CON: Only crypto primitive, no certificate, no TLS
B. Libsodium: https://doc.libsodium.org/, https://github.com/jedisct1/libsodium (ISC license) - CON: Only crypto primitive, no certificate, no TLS
C: BoringSSL: https://github.com/google/boringssl (ISC license) - CON: Google only project. It says: "We don't recommend that third parties depend upon it."
D: WolfSSL: https://www.wolfssl.com/, https://github.com/wolfSSL/wolfssl (GPL license) - CON: GPL License issue.
E: BearSSL: https://bearssl.org/ (MIT license) - CON: Current version is 0.6. It is now considered beta-quality software.

[Proposal]
1. Let's put *Openssl 3.0 POC* to *edk2-staging*, and continue the research on how to reduce the size.
It is possible that we may need add MACRO to Openssl 3.0 to reduce the size. We can do POC and submit to openssl community.

2. Let's put *MbedTls POC* to *edk2-staging*, and continue the research on how to add missing features.

3. If 1 or 2 can success, we can replace openssl 1.1 with one crypto lib.
If both 1 and 2 fail, we may use *dual-crypto module*. For example: mbedtls for PEI and openssl3.0 for DXE.
The source code size will become larger, more time to download the tree.

4. We need control the quality of Openssl 1.1 replacement to avoid regression.
I propose the check-in criteria below:
A) Size delta < +10%
B) No API change.
C) All existing crypto usages in EDKII are covered, including:
UEFI Secure Boot - image verification/auth variable update (PKCS7)
TCG Trusted Boot (SHA2/SM3)
UEFI/PI FMP Capsule (PKCS7/PKCS1-v1.5-RSA)
HTTPs Boot (TLS 1.2/1.3)
BIOS Password (PKCS5-PBKDF)
iSCSI (SHA2)
HDD Password (SHA2)
Hash2Dxe (SHA2)
Pkcs7Verify (PKCS7)
D) All crypto APIs in EDKII are covered besides above use case, including:
SHA3-ParallelHash
HMAC/HKDF
ECC
E) All crypto test need pass.

Please review and provide your feedback.


[Misc]
I would like to clarify my position on the original openssl 3.0 path, to avoid the misunderstanding:
A) I never expressed a desire to retain the OpenSSL 1.1. (I am sorry, if I did not say that clearly.)
B) I raised the concern that *current OpenSSL 3.0 patch requires more improvement*, because it will increase the size and break the existing platform.
It has no difference with other comment I give in the EDKII. If we want to check in, we need resolve the concern and ensure it can still work with existing platform.


Last but not least, I would like to suggest *again* that we maintain *a civil and healthy community environment*. (Thanks, Ard)
NOTE: All EDKII maintainers are doing volunteer work here. We are using development mailing list. Let's focus on technical topic.
If anyone has any constructive technical idea, feel free to express your opinion, and we are happy to listen and discuss.
Any collaboration, patch submission, and validation are more than welcome.

This is not a small work. We need all EDK-II community people's help to deal with this OpenSSL 1.1 EOL.

Thank you
Yao, Jiewen