Thoughts about signatures, JOSE, and NIST curves (was: [PROPOSED WORK ITEM] ECDSA Secp384r1 Cryptosuite v2019)

I was looking at: https://w3c-ccg.github.io/lds-jws2020/#jose-conformance
and I thought that P-256 paired with ES256, P-384 paired with ES-384, and
P-521 paired with ES-512 .
One can look at https://www.iana.org/assignments/jose/jose.xhtml to see
this:

ES256 ECDSA using P-256 and SHA-256 alg Recommended+ [IESG
<https://www.iana.org/assignments/jose/jose.xhtml#IESG>] [RFC7518, Section
3.4 <https://www.iana.org/go/rfc7518>] n/a
ES384 ECDSA using P-384 and SHA-384 alg Optional [IESG
<https://www.iana.org/assignments/jose/jose.xhtml#IESG>] [RFC7518, Section
3.4 <https://www.iana.org/go/rfc7518>] n/a
ES512 ECDSA using P-521 and SHA-512 alg Optional [IESG
<https://www.iana.org/assignments/jose/jose.xhtml#IESG>] [RFC7518, Section
3.4 <https://www.iana.org/go/rfc7518>] n/a












There are some variations in the table that I do not quite understand, but
it seems like in order to add to a library like did-jwt one would need to
support SHA-384 and SHA-512 hashing to support curves like P-384 and P-512.







In the table, https://w3c-ccg.github.io/lds-jws2020/#jose-conformance I see
ECDH-ES+A256KW for ES256, ES384, and ES512.

ECDH-ES+A256KW is mentioned in
https://www.iana.org/assignments/jose/jose.xhtml
ECDH-ES+A256KW ECDH-ES using Concat KDF and "A256KW" wrapping alg
Recommended [IESG
<https://www.iana.org/assignments/jose/jose.xhtml#IESG>] [RFC7518,
Section 4.6 <https://www.iana.org/go/rfc7518>] n/awhich is further
described in https://www.rfc-editor.org/rfc/rfc7518.html

I've definitely seen some code for P-384 and P-521 over in the the
transmute repositories :
https://github.com/transmute-industries/did-key.js/tree/main/packages/did-key-web-crypto
,
https://github.com/transmute-industries/verifiable-data/tree/main/packages/web-crypto-key-pair/src

I am not sure what ECDH-ES+A256KW is yet.

I know Kim Duffy proposed a naming scheme in 2018:

<curve-specific><purpose>Key<date>
https://lists.w3.org/Archives/Public/public-credentials/2018Mar/0104.html


In my own attempts to get P-256 support, I presently am not considering
stuff like Secp256r1VerificationKey2022 or P256Key2021 because this seems
to be coupled to application/did+ld+json . Instead, rather than deciding,
I'm going for JsonWebKey2020 which seems to be geared for
application/did+json .
I guess more about the application ... (media types) is here:
https://github.com/w3c/did-core/issues/208

I am personally interested in P-256 support. I need a did-provider, and for
my purposes, the did-jwt library (
https://github.com/decentralized-identity/did-jwt) seemed to be the one I
needed to modify. Due to some attempts at refactoring a signer for P-384
and P-521 looks like it could be added with a clear break from the rest of
the code base. I must admit I wasn't there during the development of
did-jwt so I'm trying to figure out the code and its motivation as I go.

I thought about P-384 and P-521 from the resolver side. I helped with some
test-vectors for did:key, and threw it in a PR for a resolver. I probably
won't do much more with P-384 or P-521, at least for a month? I'm working
with a device called a cryptographic co-processor which sent me on the
P-256 journey.

-Brent Shambaugh