Add ECDSA_P384_SHA256_FIXED to ecdsa verification

[dodomorandi]

As commented in this issue, it should be pretty trivial to add support for ECDSA_P384_SHA256_FIXED.

Is there any particular reason the implementation is not already available? I just want to be sure that it is not been explicitly omitted for reasons.

[briansmith]

I was hoping to not have to add it. I think we only need it for specific legacy uses? I suggest:

• We add it and name it ECDSA_P384_SHA256_FIXED_FOR_LEGACY_USE_ONLY.
• The PR that adds it must come with tests in the same style as the tests for the other variants. In particular, whatever tests we filtered out of the NIST and/or BoringSSL test suites for this variant must be added back so our coverage is at least as good as the NIST/BoringSSL test suites.
• The code that signs a hash must be double-checked to ensure it doesn't make assumptions that the hash is the same size as the signature (in bits/bytes/words). It might need to be adjusted; if so, then at least one of the aforementioned tests should fail without these adjustments.

[dodomorandi]

Ok, this is the kind of thing I wanted to hear. From your words, this algorithm is substantially deprecated and it should not be used, right? The issue I linked is related to the validation of Digital Green Pass, definitely not something that should use legacy/deprecated approaches. I don't have the knowledge to assess why it should not be used, but I feel that I can trust you. For my specific use-case, there is a good chance this specific algorithm should not have been used at all, therefore I feel more confident to refuse to validate the signed message than taking some security issues.

Tell me if this makes sense, and if you think that it is better to leave ECDSA_P384_SHA256_FIXED unimplemented (because, you know, _FOR_LEGACY_USE_ONLY won't stop people doing silly things), feel free to close the issue. Thank you for your time and your support!