Goal

Allow us to correctly negotiate ML-DSA signatures.

Why

We fail to negotiate ML-DSA with the new release of OpenSSL

    Updating openssl-src v300.5.4+3.5.4 -> v300.5.5+3.5.5

This change broke our CI.

This OpenSSL release included a stricter, more correct behavior

• openssl/openssl@f5bfeee
• ML-DSA signatures with not matching schemes in TLS are accepted openssl/openssl#28762

This broke us because our signature selection was not certificate aware. We were loading ML-DSA-87 certs

        let cert_path = format!("{TEST_PEMS_PATH}mldsa/ML-DSA-87.crt");
        let key_path = format!("{TEST_PEMS_PATH}mldsa/ML-DSA-87-seed.priv");

But the cert verify that the s2n-tls server was sending was not mldsa87

        Handshake(
            CertVerifyTls13(
                CertVerifyTls13 {
                    algorithm: SignatureScheme {
                        value: 2308,
                        description: "mldsa44",
                    },
                    signature: PrefixedBlob(
                        4627,
                    ),
                },
            ),
        ),

How

We updated the signature selection to properly handle MLDSA signatures. I also added an "else" case so any new certificate type will explicitly fail unless we handle it.

Related

Also, I am pinning time to get the CI to pass. That is blocking a different PR to fix the rust toolchains in the Nix stuff.

Testing

CI should pass

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