Add JSON Web Key Elliptic Curves from IANA

[OR13]

https://www.iana.org/assignments/jose/jose.xhtml#web-key-elliptic-curve

p256-pub,                       multihash,      0x1200,         P-256 Public Key
p384-pub,                       multihash,      0x1201,         P-384 Public Key
p521-pub,                       multihash,      0x1202,         P-521 Public Key
ed448-pub,                      multihash,      0x1203,         Ed448 Public Key
x448-pub,                       multihash,      0x1204,         X448 Public Key

[OR13]

@rvagg let me know if I got this wrong.

[vmx]

I know almost nothing about JSON Web Key Elliptic Curves, but from the name of the codecs, it sounds like their category should be key instead of multihash, similar to secp256k1-pub or ed25519-pub

[OR13]

@vmx uggh... nice catch... I have labled them "key" :)

[rvagg]

Sorry, I've been a little hung up pondering the ordering of these. You've now got the complete set for JOSE and COSE (in current spec at least), but you've not got the complete list of curves that people might want added, and those additions would fit in between this list, so I've been wondering how much we should care about that problem.

I don't know whether we should attempt to make space for some categorisation here, EC isn't a strong point for me so I'm not sure how meaningful it would be. For example, in the Weierstrass category there's P-192 and P-224 that NIST list that would fit before the ones you have, and there's also W-25519 and W-448 that could arguably fit afterward, plus potentially more. An Edwards category has a few 25519 and 448 variants as well as E-222 and E-521 from NIST. But you could also break them down into twisted and untwisted sub-categories! A Montgomery category would fit the X-448 and the X-25519 we already have I think but there's also a few variations on those, plus the M- curves from NIST. There's Koblitz and Pesudorandom from NIST too that we haven't touched at all yet.

I'm not sure whether people are going to want to add any of these in the future and whether we should have a bit more organisation in the categories here or just slot them in on a first-come-first-served basis (and perhaps I'm overthinking it!)

Does anyone else have an opinion on whether we should make at least a bit of an attempt to space these out a bit? Maybe put 2 spaces for P-192 and P-224 at the start and then pad the others out into blocks of 0x000f? Or just add these as they are and let them pile up in here as requests come?

Also minor nit @OR13: s/Public Key/public key for consistency.

[OR13]

@rvagg thanks!

regarding spacing things out... I feel like a csv is searchable enough, and we should be first come first serve, and worry less about what the actual byte prefixes ar...in other words, not create gaps that might never get filled, and not worry if similar things are not right next to each other.

[rvagg]

I feel like a csv is searchable enough, and we should be first come first serve

Yeah, nobody else seems too concerned and the table is already somewhat scattered so there's precedent for this.

Will merge this tomorrow if nobody objects and someone else doesn't beat me to it.

[rvagg]

If you want to use these in one of the downstream libraries you may need to PR an update there, that's not an automatic process yet. https://github.com/multiformats/js-multicodec has an update-table npm script to do this if that's where you want to consume it.