certificate_signature_preferences field contains unnecessary information about s2n-tls HOT 2 OPEN

However, having this included in the signature preferences might be confusing to readers because the secp256r1 part of the signature is never validated.

Why is one of the possible solutions not to start enforcing the secp256rl part of the signature scheme?

Given only a single certificate and it's signature, you can't tell whether the signing key had an OID of rsaEncryption or rsassaPss, so we can't distinguish between s2n_rsa_pss_pss_sha512 and s2n_rsa_pss_rsae_sha512.

We have the full certificate chain though, don't we? Why can't we consider more than one certificate at a time?

from s2n-tls.

Why is one of the possible solutions not to start enforcing the secp256rl part of the signature scheme?

Given a goal of enforcing "key preferences", enforcing the key type in the IANA signature scheme would be necessary but not sufficient. IANA signature schemes are generally poorly suited to representing signature and key preferences because (nonexhaustively)

1. They don't include size information about RSA keys certs
2. They suffer from combinatoric qualities. For example there would be ~ 24 rsassaPss schemes.|rsa sizes| * |rsa OID types| * |digest sizes|

We have the full certificate chain though, don't we?

We do have the full certificate chain, but only after validation, and all of its requisite expensive crypto operations have completed. If we are going to reject a cert, we should do that as early as possible to avoid throwing away work. Implementing path-aware validation before X509_verify has completed would mean that s2n-tls has to figure out the potential path. While this is solvable, it's complexity that I would prefer not to deal with.

from s2n-tls.