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

In general, IETF controls the algorithm registries for JSON and CBOR key
representations, signing and encryption.

There are numerous implementations of these suites in pretty much every
major language, which makes interoperability testing pretty easy.

For newer crypto like ES256K, you should be careful because not every
library will implement them the same way, and you may need to "normalize to
lower s" even though it's not in the IETF spec.

"Multicodec" is basically controlled by the IPFS community, see
https://github.com/multiformats/multicodec/blob/master/table.csv

I would strongly recommend building on one or the other, or both, and not
attempting to invent anything new that is not directly compatible with them.

OS

ᐧ

On Mon, Jan 24, 2022 at 10:47 AM Brent Shambaugh <brent.shambaugh@gmail.com>
wrote:

> 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
>


-- 
*ORIE STEELE*
Chief Technical Officer
www.transmute.industries

<https://www.transmute.industries>