[jose] Working group adoption of “COSE and JOSE Registrations for WebAuthn Algorithms”

[Mike Jones <[e-mail]>]

FYI, a draft that registers JOSE identifiers for signing with the secp256k1 curve was adopted by COSE this week.  See http://self-issued.info/?p=1964.  Please discuss it on the [e-mail]<mailto:[e-mail]> mailing list.

Also, please respond on the COSE mailing list about the identifier choice for the curve.  Per the note below, two names are being considered “P-256K” and “secp256k1”.

                                                          -- Mike

From: COSE <[e-mail]> On Behalf Of Filip Skokan
Sent: Wednesday, March 27, 2019 2:17 PM
To: [e-mail]
Subject: [COSE] "P-256K" in draft-ietf-cose-webauthn-algorithms

Hello,

Once more to the correct mailing list...

this draft has caught my attention since it touches JOSE as well, specifically it proposes registration for the uses of secp256k1 "bitcoin" curve. I learned from Mike Jones that there's a discussion around naming the key's curve and the JWA algorithm.

- "P-256K"
Do we really need a new name for secp256k1? I would suggest not. Most of the document talks about secp256k1 anyway. Giving secp256k1 the alias P-256K gives the impression that it is a curve standardized by NIST, which it is not. Mike> Others have also suggested simply using the name "secp256k1". I'm fine with that.

I'd like to advocate for sticking with the proposed (in current draft) "P-256K" for EC key's crv, and "ES256K" for the JWA alg. These values are already quite common in existing implementations, quite a few hits for this.

[1] https://docs.microsoft.com/en-us/dotnet/api/microsoft.azure.keyvault.eckey.p256k?view=azure-dotnet
[2] https://connect2id.com/products/nimbus-jose-jwt/examples/jwt-with-es256k-signature
[3] https://static.javadoc.io/com.nimbusds/nimbus-jose-jwt/5.10/com/nimbusds/jose/jwk/ECKey.html
[4] https://github.com/panva/jose/blob/master/lib/jwk/key/ec.js#L22-L23
[5] https://github.com/relocately/ec-key

As mentioned in the IETF 104 meeting on Tuesday the other encountered naming of this is "K-256" but there's considerably less hits searching for implementations using that one.

I understand the COSE group does not (probably) have existing implementations of secp256k1 and that's why the notion of just naming it secp256k1 resonates, but maybe consider only doing so for COSE. JOSE could use less fragmentation amongst its implementations and therefore sticking to the most common naming already in the wild would be welcome.

The same applies to the presented question about Compressed vs. Non-compressed Points for secp256k1, i'd advocate that at least for JOSE the used points remain in-line with what's already used in with the existing keys and algorithms.

Best,
Filip Skokan