Should we support ES256 DSA?

[amika-sq]

In the previous requirements doc, there was a stretch goal of supporting secp256r1.

This may be a misunderstanding on my part, but I believe that ES256K is only used for secp256k1. Wondering if we should be tracking support for the other, or if that's no longer a goal

[mistermoe]

I believe the reason secp256r1 was added was because we wanted to support 1 FIPS compliant algorithm. But secp256k1 is also FIPS compliant so i left it out. at least for now

@frankhinek can you think of any other reasons as to why secp256r1 should be supported?

[frankhinek]

@mistermoe I suppose it depends on whether we expect any partners / participants to follow U.S. Federal recommendations?

If that matters, we ought to consider that as of the most recent publication, FIPS 186-5, the guidelines for elliptic curves suitable for Federal government use have been moved to NIST SP 800-186.

Notable is:

• Addition of 25519 and 448 curves (in Montgomery, Edwards and Weierstrass forms)
• "Allowed" usage of some Brainpool curves
• Addition of secp256k1 but only for "blockchain-related applications"

[decentralgabe]

P-256 is good to support since it's supported by existing HSMs/KMS. The code for ECDSA is quite similar to the code for ES256K (often uses the same lib, as was the case in the go impl).

[decentralgabe]

this is supported