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
In 3.6, many X.509 test cases depend on MBEDTLS_PK_CAN_ECDSA_SOME. This looks wrong.
MBEDTLS_PK_CAN_ECDSA_SOME indicates that either ECDSA signature or ECDSA verification is enabled, but not necessarily both. It's only possible to set up a configuration with only one direction by providing drivers only for one direction (enabling built-in ECDSA automatically provides both). And I don't think we can currently have signature without verification, but in principle we do have verification without signature (disable built-in ECC and provide accelerators only for ECC public keys and ECC algorithms, not for ECC key pairs).
X.509 tests need ECDSA for verification, for signature, or for both. I don't think there are any X.509 test cases that should run if either direction is enabled but not if neither is enabled. I don't even expect many PK test cases to run if either direction is enabled but not if neither is enabled. MBEDTLS_PK_CAN_ECDSA_SOME is mostly for some auxiliary functions that are relevant with either ECDSA direction.
The goal of this issue is to review all depends_on guards using MBEDTLS_PK_CAN_ECDSA_SOME in unit tests, and change them to MBEDTLS_PK_CAN_ECDSA_VERIFY if the test case only uses verification, MBEDTLS_PK_CAN_ECDSA_SIGN if the test case only uses signature, or MBEDTLS_PK_CAN_ECDSA_SIGN:MBEDTLS_PK_CAN_ECDSA_VERIFY if the test case uses both (that's likely to be the case in SSL tests). There may also be test cases that don't require either, only MBEDTLS_PK_HAVE_ECC_KEYS, for example when an X.509 test case only does parsing, or when it's verifying a certificate for an ECC key but the CA(s) involved use an RSA key.
This applies at least to 3.6. This applies to development as well at the time of writing, but will become moot very soon when #9337 is done. This does not apply to 2.28 which doesn't have MBEDTLS_PK_CAN_ECDSA_xxx.
The text was updated successfully, but these errors were encountered:
In a legacy configuration: MBEDTLS_ECDSA_C provides both public-key and private-key support.
In a PSA configuration: PSA_WANT_KEY_TYPE_ECC_KEY_PAIR implies PSA_WANT_KEY_TYPE_ECC_PUBLIC_KEY and we have no desire to change that.
So MBEDTLS_PK_CAN_ECDSA_SOME is effectively synonymous with MBEDTLS_PK_CAN_ECDSA_VERIFY. We should just double-check if there's any place where it should be replaced by MBEDTLS_PK_CAN_ECDSA_SIGN.
In 3.6, many X.509 test cases depend on
MBEDTLS_PK_CAN_ECDSA_SOME
. This looks wrong.MBEDTLS_PK_CAN_ECDSA_SOME
indicates that either ECDSA signature or ECDSA verification is enabled, but not necessarily both. It's only possible to set up a configuration with only one direction by providing drivers only for one direction (enabling built-in ECDSA automatically provides both). And I don't think we can currently have signature without verification, but in principle we do have verification without signature (disable built-in ECC and provide accelerators only for ECC public keys and ECC algorithms, not for ECC key pairs).X.509 tests need ECDSA for verification, for signature, or for both. I don't think there are any X.509 test cases that should run if either direction is enabled but not if neither is enabled. I don't even expect many PK test cases to run if either direction is enabled but not if neither is enabled.
MBEDTLS_PK_CAN_ECDSA_SOME
is mostly for some auxiliary functions that are relevant with either ECDSA direction.The goal of this issue is to review all
depends_on
guards usingMBEDTLS_PK_CAN_ECDSA_SOME
in unit tests, and change them toMBEDTLS_PK_CAN_ECDSA_VERIFY
if the test case only uses verification,MBEDTLS_PK_CAN_ECDSA_SIGN
if the test case only uses signature, orMBEDTLS_PK_CAN_ECDSA_SIGN:MBEDTLS_PK_CAN_ECDSA_VERIFY
if the test case uses both (that's likely to be the case in SSL tests). There may also be test cases that don't require either, onlyMBEDTLS_PK_HAVE_ECC_KEYS
, for example when an X.509 test case only does parsing, or when it's verifying a certificate for an ECC key but the CA(s) involved use an RSA key.This applies at least to 3.6. This applies to
development
as well at the time of writing, but will become moot very soon when #9337 is done. This does not apply to 2.28 which doesn't haveMBEDTLS_PK_CAN_ECDSA_xxx
.The text was updated successfully, but these errors were encountered: