Should MBEDTLS_PSA_CRYPTO_CLIENT be a configuration option? #112

New issue

Open

opened 2024-10-04 09:21:33 -05:00 by gilles-peskine-arm · 2 comments

gilles-peskine-arm commented

2024-10-04 09:21:33 -05:00

(Migrated from github.com)

From Mbed TLS 3.x, we've inherited MBEDTLS_PSA_CRYPTO_CLIENT as an option guarding client-side PSA crypto code, a small subset of MBEDTLS_PSA_CRYPTO_C which covers the generic PSA crypto code (key store functionality, generic dispatch code). Should we keep supporting builds without MBEDTLS_PSA_CRYPTO_CLIENT? On the one hand, you can't have any stable API for cryptography. On the other hand, this could be ok for corner cases, e.g. just for ASN.1.

Tentative definition of done — may be revised based on the architectural decision:

If we do keep MBEDTLS_PSA_CRYPTO_CLIENT as an option, there should be an all.sh component that builds the library with it disabled.
~~If we don't want MBEDTLS_PSA_CRYPTO_CLIENT as an option, it shouldn't be listed in the configuration file, and in fact it probably shouldn't appear in the library source code at all.~~

From Mbed TLS 3.x, we've inherited `MBEDTLS_PSA_CRYPTO_CLIENT` as an option guarding client-side PSA crypto code, a small subset of `MBEDTLS_PSA_CRYPTO_C` which covers the generic PSA crypto code (key store functionality, generic dispatch code). Should we keep supporting builds without `MBEDTLS_PSA_CRYPTO_CLIENT`? On the one hand, you can't have any stable API for cryptography. On the other hand, this could be ok for corner cases, e.g. just for ASN.1. Tentative definition of done — may be revised based on the architectural decision: * If we do keep `MBEDTLS_PSA_CRYPTO_CLIENT` as an option, there should be an `all.sh` component that builds the library with it disabled. * ~If we don't want `MBEDTLS_PSA_CRYPTO_CLIENT` as an option, it shouldn't be listed in the configuration file, and in fact it probably shouldn't appear in the library source code at all.~

mpg commented

2025-09-30 05:14:26 -05:00

(Migrated from github.com)

I think we've discussed recently that we should keep it as an option in the unlikely case someone want to build just the non-crypto parts of the library (base64, PEM, asn1...)

If we do keep MBEDTLS_PSA_CRYPTO_CLIENT as an option, there should be an all.sh component that builds the library with it disabled.

Good point. The easiest way to achieve that is probably with a new file configs/no-psa-crypto.h that would just enable the few options that don't depend on MBEDTLS_PSA_CRYPTO_CLIENT. Everything else should explicitly depend on MBEDTLS_PSA_CRYPTO_CLIENT unless it already depends on MBEDTLS_PSA_CRYPTO_C.

This is all very low priority though I think.

I think we've discussed recently that we should keep it as an option in the unlikely case someone want to build just the non-crypto parts of the library (base64, PEM, asn1...) > If we do keep `MBEDTLS_PSA_CRYPTO_CLIENT` as an option, there should be an `all.sh` component that builds the library with it disabled. Good point. The easiest way to achieve that is probably with a new file `configs/no-psa-crypto.h` that would just enable the few options that don't depend on `MBEDTLS_PSA_CRYPTO_CLIENT`. Everything else should explicitly depend on `MBEDTLS_PSA_CRYPTO_CLIENT` unless it already depends on `MBEDTLS_PSA_CRYPTO_C`. This is all very low priority though I think.

gilles-peskine-arm commented

2025-09-30 09:38:07 -05:00

(Migrated from github.com)

We're still far from there, but in the meantime, we shouldn't make the situation worse when MBEDTLS_PSA_CRYPTO_CLIENT is disabled. In the short term, I think we should test TF-PSA-Crypto with MBEDTLS_PSA_CRYPTO_CLIENT and MBEDTLS_PK_C disabled, but all other features enabled.

There's demand for using the X.509 and TLS libraries in Mbed TLS with other implementations of the PSA Crypto API. It would be unrealistic to build Mbed TLS without TF-PSA-Crypto at all. However, it would make sense to build Mbed TLS against an alternative implementation of the PSA Crypto API, plus some bits of TF-PSA-Crypto such as ASN.1 and PK. That would be a build of TF-PSA-Crypto with `MBEDTLS_PSA_CRYPTO_CLIENT` disabled. We're still far from there, but in the meantime, we shouldn't make the situation worse when `MBEDTLS_PSA_CRYPTO_CLIENT` is disabled. In the short term, I think we should test TF-PSA-Crypto with `MBEDTLS_PSA_CRYPTO_CLIENT` and `MBEDTLS_PK_C` disabled, but all other features enabled.

No milestone

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

gh-Mbed-TLS/TF-PSA-Crypto#112

No description provided.

Rows
Columns