You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This task is to progress TL-ecdsa.TLS by achieving testing parity in the SSL test suites (including debug which is part of SSL despite its name not reflecting it). Once it's done, in analyze_outcomes.py, the task analyze_driver_vs_reference_ecdsa will no longer ignore ssl nor debug.
This will likely consist of replacing uses of MBEDTLS_ECDSA_C with either:
checks based on MBEDTLS_KEY_EXCHANGE_xxx macros for most TLS 1.2 code (we may want to introduce a new macro to express "there's a key exchange that requires ECDSA" / "allows use of ECDSA" (client auth, see below), similarly to the existing MBEDTLS_SSL_HANDSHAKE_WITH_CERT_ENABLED);
PSA_WANT_ALG_ECDSA for TLS 1.3 code that calls PSA functions directly (if any).
Note that most of the time, MBEDTLS_KEY_EXCHANGE_xxx is the right choice: it doesn't matter that the library can do ECDSA if no key exchange using ECDSA is enabled. (It's also a matter of layering: we should not use feature macros from low-level modules if there are some closer to our level that can do the job.) However there are places where the choice of a signature algorithm is not determined by the key exchange. The one (and only one) I can think of is client authentication: even if the key exchange is RSA, it's legal for a client to authenticate itself using an ECDSA. So, when negotiating signature algorithms for client authentication, going to PK macros is probably the right thing to do.
For debug, we may choose to change the output format when USE_PSA is enabled.
Note: since this modifies dependency declarations, we'll want to use docs/architecture/psa-migration/outcome-analysis.sh on the PR that implements this.
Note: enabling more key exchanges in config_psa_crypto_config_ecdsa_use_psa is out of scope here, it will be a separate task.
Context: #6839.
This task is to progress TL-ecdsa.TLS by achieving testing parity in the SSL test suites (including debug which is part of SSL despite its name not reflecting it). Once it's done, in
analyze_outcomes.py
, the taskanalyze_driver_vs_reference_ecdsa
will no longer ignoressl
nordebug
.This will likely consist of replacing uses of
MBEDTLS_ECDSA_C
with either:MBEDTLS_KEY_EXCHANGE_xxx
macros for most TLS 1.2 code (we may want to introduce a new macro to express "there's a key exchange that requires ECDSA" / "allows use of ECDSA" (client auth, see below), similarly to the existingMBEDTLS_SSL_HANDSHAKE_WITH_CERT_ENABLED
);PSA_WANT_ALG_ECDSA
for TLS 1.3 code that calls PSA functions directly (if any).Note that most of the time,
MBEDTLS_KEY_EXCHANGE_xxx
is the right choice: it doesn't matter that the library can do ECDSA if no key exchange using ECDSA is enabled. (It's also a matter of layering: we should not use feature macros from low-level modules if there are some closer to our level that can do the job.) However there are places where the choice of a signature algorithm is not determined by the key exchange. The one (and only one) I can think of is client authentication: even if the key exchange is RSA, it's legal for a client to authenticate itself using an ECDSA. So, when negotiating signature algorithms for client authentication, going to PK macros is probably the right thing to do.For debug, we may choose to change the output format when
USE_PSA
is enabled.Note: since this modifies dependency declarations, we'll want to use
docs/architecture/psa-migration/outcome-analysis.sh
on the PR that implements this.Note: enabling more key exchanges in
config_psa_crypto_config_ecdsa_use_psa
is out of scope here, it will be a separate task.Depends on: #6858
The text was updated successfully, but these errors were encountered: