ecdsa_secp256r1_sha384_test.json, ecdsa_secp256r1_sha512_test.json, and ecdsa_secp384r1_sha256_test.json are missing

[briansmith]

These unusual combinations of P-256 + {SHA-384, SHA-512} and P-384 + SHA-256 are supported in some crypto libraries, for backward compatibility with some TLS implementations. However, there are no test vectors for these combinations. It would be great to include the test vectors for these in the open source release. (P-256 + SHA-512 is arguably even a useful combination since SHA-512 is faster than SHA-256 on many platforms, and probably stronger, even/especially when truncated in half.)

[thaidn]

@bleichen

[bleichen]

I'm adding more files for more curve/hash combination.
I'm however not sure about ecdsa_secp384r1_sha256.
This combination makes little sense since the security of the hash is
weaker than the curve. There are a few test vectors in ecdsa_test.json,
though these are marked as legacy cases. I.e. the result is "acceptable",
which means that I expect that some libraries reject such keys and signatures.

[briansmith]

I'm however not sure about ecdsa_secp384r1_sha256.
This combination makes little sense since the security of the hash is
weaker than the curve.

I agree it doesn't make sense. Unfortunately, before TLS 1.3, TLS clients can advertise "ECDSA + SHA-384" and "ECDSA + SHA-256" but they can't advertise which curves they support for each digest algorithm, since the supported curves are negotiated in a separate parameter. (In TLS 1.3 there is a fixed mapping: SHA-256 with P-256, SHA-384 with P-384.) A web-compatible TLS implementation either has to decide to reject signatures for which it technically advertised support or support this weird combination. I believe many implementations have chosen to support this weird combination.

[thaidn]

ecdsa_secp256r1_sha512_test.json was added.