Fallback cryptographic primitives support in x509 parsing

[learn-more]

Suggested enhancement

In #4084 there are a bunch of ancient / obsolete primitives removed for ease of maintenance. However in some cases it might be useful for applications to at least partially support extra stuff.

Would you be open to some hooks in the code (like for example mbedtls_platform_set_calloc_free) to support custom / alternate primitives?

Justification

Mbed TLS might need this because it allows users of the library to add unsupported / obsolete (or custom) algorithms without cluttering the mbedtls library.

[gilles-peskine-arm]

Mbed TLS supports cryptography drivers, which allow you to plug in your own implementation of an algorithm that Mbed TLS supports. However, you can't plug in an algorithm that Mbed TLS doesn't support. The reason is that implementing an algorithm is more than just plugging in a function. We have a checklist for that (and I'm not completely sure that check list is up to date). The library has to know which keys are compatible with which algorithms, which algorithms are compatible with which operations, what the key sizes are, how keys are represented, etc.

Furthermore there's a contract between the library core and driver regarding what the core validates. This contract is currently unwritten (and I hope we can clarify it in 2025). Generally we want the library core to validate everything it can so that drivers can focus on taking advantage of specific hardware, and users can be confident that their application won't suddenly accept invalid inputs when they move from device A to device B.

All of these problems are solvable in principle. And it's something we're already thinking of doing, mostly for newer algorithms that we haven't integrated yet, especially when they're provided by a secure element. But it's a lot of work, and it's not work that we have the time for in the short or even middle term.

[learn-more]

Sorry, I should probably have specified that this is in the context of parsing an x509 certificate (I have amended the original question). For testing locally I have now applied a patch like this, that allows me to hook into the parsing of the certificate:

---
 vendor/mbedtls/library/x509.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/vendor/mbedtls/library/x509.c b/vendor/mbedtls/library/x509.c
index f97fb44..2e3f7c6 100644
--- a/vendor/mbedtls/library/x509.c
+++ b/vendor/mbedtls/library/x509.c
@@ -43,6 +43,10 @@
 #include <time.h>
 #endif

+int platform_oid_get_sig_alg(const mbedtls_asn1_buf* oid,
+    mbedtls_md_type_t* md_alg, mbedtls_pk_type_t* pk_alg, void** sig_opts);
+
+
 #define CHECK(code)                                     \
     do {                                                \
         if ((ret = (code)) != 0) {                      \
@@ -726,6 +730,9 @@ int mbedtls_x509_get_sig_alg(const mbedtls_x509_buf *sig_oid, const mbedtls_x509
     }

     if ((ret = mbedtls_oid_get_sig_alg(sig_oid, md_alg, pk_alg)) != 0) {
+        if (platform_oid_get_sig_alg(sig_oid, md_alg, pk_alg, sig_opts) == 0) {
+            return 0;
+        }
         return MBEDTLS_ERROR_ADD(MBEDTLS_ERR_X509_UNKNOWN_SIG_ALG, ret);
     }

[gilles-peskine-arm]

Ah, I see. I had misunderstood. It's not clear to me how this can work. We could (not easily) add a way to support custom OIDs (at compile time? at run time?). Then what? Even if you can parse the certificate, you wouldn't be able to verify it unless the cryptographic primitives are available as well, and X.509 understands them. (For hashes, just supporting crypto and OIDs might be enough. For a new signature method, X.509 itself has a quite a few places with code that's specific to RSA vs ECC.)