Deterministic ML-DSA/SLH-DSA key policies not consistent with ECDSA

[athoelke]

Reported by an implementation developer:

Yesterday, another API question regarding ML-DSA came up. The beta spec requires that a key policy that permits PSA_ALG_ML_DSA should be combatible with PSA_ALG_DETERMINISTIC_ML_DSA. This is limited to psa_verify_message() for obvious reasons.

To be consistent, this special rule should be also applied to PSA_ALG_ECDSA/PSA_ALG_DETERMINISTIC_ECDSA. However, wouldn't it be simpler to remove the special rule for ML-DSA altogether? We think the benefit of that rule is rather small.

[athoelke]

During the development of the PQC Extension, handling of Hedged and Deterministic variants of the ML-DSA and SLH-DSA algorithms provoked some discussion. Some of that is captured in the #216 PR. The result was special handling of the key policy for these algorithms.

For example, see https://arm-software.github.io/psa-api/crypto/1.3/ext-pqc/api/mldsa.html#c.PSA_ALG_ML_DSA, which says:

When PSA_ALG_ML_DSA is used as a permitted algorithm in a key policy, this permits:

• PSA_ALG_ML_DSA as the algorithm in a call to psa_sign_message().
• PSA_ALG_ML_DSA or PSA_ALG_DETERMINISTIC_ML_DSA as the algorithm in a call to psa_verify_message().

If we remove the special behavior, to align with the ECDSA algorithm, this is not particularly problematic for applications. The application can either choose to always import public keys under the same algorithm identifier that is used to perform the verification; or always use the key's permitted-algorithm when performing the verification.

[athoelke]

this is not particularly problematic for applications

But appraently, it is still awkward.

When dealing with TLS authentication for ECDSA in MbedTLS:

• The library is not always in control of importing the public key - so cannot enforce that one or other specific algorithm ids is used for the permitted-algorithm policy.
• So the library attempts to use PSA_ALG_ECDSA() for signature verification, but if that fails with PSA_ERROR_NOT_PERMITTED, will try again with PSA_ALG_DETERMINISTIC_ECDSA().
• Retrieving the key attributes to recover the permitted algorithm, and resetting the attributes is an alternative, but is no less disruptive in the application flow.

There is a preference for relaxing the policy for ECDSA to align with the proposed ML-DSA and SLH-DSA polices so that the policy behaviour is consistent with the fact that the PSA_ALG_ECDSA() and PSA_ALG_DETERMINISTIC_ECDSA() are identical for verification. This would enable simplification of application use cases like this.

So, adding logic to the policy verification for these three algorithms for usage PSA_KEY_USAGE_VERIFY_HASH or PSA_KEY_USAGE_VERIFY_MESSAGE might be a better trade off?

[athoelke]

Current proposal: relax the policy verification for the ECDSA algorithms, to match the policy checking that is described in the PQC Extension for SLH-DSA and ML-DSA.

Plan to include this in v1.4.0.