failing on secp256r1 curve

[m-zielinski]

'secp256r1' curve name is not supported. Worse - it rises an ambiguous message: "payload algorithm is ES256 but signing key was provided". That's because JWT::Algos::Ecdsa::NAMED_CURVES has no 'secp256r1' key.

Question: Is it deliberate or may I make a pull request to fix this (add the curve name to NAMED_CURVES and fix the exception message for future unlisted names)?

How to reproduce:

ecdsa_key = OpenSSL::PKey::EC.new 'secp256r1'
ecdsa_key.generate_key
ecdsa_key.check_key # true
JWT.encode "", ecdsa_key, 'ES256' # raises: JWT::IncorrectAlgorithm (payload algorithm is ES256 but  signing key was provided)

[obulkin]

Running into this issue as well. We have a stored key generated using openssl ecparam -name prime256v1, but when we ingest it into OpenSSL in code, the resulting key object has the secp256r1 curve name.

My understanding is that prime256v1 and secp256r1 are two different names for the same curve, so it would be great if you could update NAMED_CURVES to support both names. We're having to work around this in very hacky ways.

[anakinj]

Think you're right. openssl describes the two curves like this:

secp256k1 : SECG curve over a 256 bit prime field
prime256v1: X9.62/SECG curve over a 256 bit prime field

I might take a look at this at some point.

[anakinj]

But hmm secp256r1 is not the same as secp256k1 or maybe they are very similar but with some (for this context trivial) differences.

Should all 3 curves secp256r1, secp256k1, prime256v1 be treated the equal in this context?

[obulkin]

According to https://tools.ietf.org/search/rfc4492#appendix-A, secp256k1 is a separate curve, but secp256r1 and prime256v1 are just aliases. I don't really know enough about cryptography and what this library is doing to confidently say whether secp256k1 should also be lumped in with the other two.

[anakinj]

This was a pretty interesting and easy read on the subject: https://www.johndcook.com/blog/2018/08/21/a-tale-of-two-elliptic-curves/

I think you're right, lets keep the secp256k1 out of this and just treat secp256r1 and prime256v1 as the same.

[anakinj]

Think #385 should fix this problem

[anakinj]

Closing this. The support for secp256r1 as an alias for prime256v1 was added a while ago.