Goal

Validate the ML-DSA key type matches the key parameter of an ML-DSA signature

Why

When verifying a CertificateVerify message signed by an ML-DSA key, s2n-tls only enforces the signatures type (i.e. ML-DSA), not the key type (44/65/87). As the cnsa2 policy added by #5760 only allows ML-DSA-87 for signing, we need to distinguish the differences and assert the correct key type is being used.

How

Invoke the EVP_PKEY_pqdsa_get_type() API to parse the ML-DSA key type (parameter size) from evp_key and compare with the one indicated by the signature scheme. s2n_tls13_cert_verify_recv() should fail the handshake if the public key does not match the signature scheme.

Callouts

I bumped the expected AWSLC_API_VERSION of the sanity check in s2n_mldsa_test as this PR changed the ML-DSA feature probe. I checked the CodeBuild logs and confirmed the ML-DSA feature flag was set to true after upgrading the AWS-LC versions in nix and Docker:

-- feature S2N_LIBCRYPTO_SUPPORTS_MLDSA: TRUE

The current AWSLC_API_VERSION is 35. The CI should continue to pass when it is bumped to 36.

Testing

I added a unit test where the client is configured with the cnsa_2 policy and the server sends an ML-DSA-87 signature with an ML-DSA-44 cert key. s2n_tls13_cert_verify_recv() succeeded before my changes and failed properly after enforcing the key type validation.

ML-DSA is only supported by TLS 1.3, which calls the same handler (s2n_tls13_cert_verify_recv) for receiving CertVerify on both server side and client side. There also exists an mTLS test case for ECDSA signatures, so I did not add the mTLS case for the ML-DSA test. Let me know if it is worth adding one.

Related

resolves #5740

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.