More discussion on the thread “[COSE] "P-256K" in
draft-ietf-cose-webauthn-algorithms” would be useful. Currently two people
have requested that “secp256k1” be used and two people have requested that
“P-256K” be used. Please speak up on the COSE mailing list.
-- Mike
From: jose <[email protected]> On Behalf Of Mike Jones
Sent: Friday, March 29, 2019 4:56 AM
To: [email protected]
Cc: [email protected]
Subject: [jose] Working group adoption of “COSE and JOSE Registrations for
WebAuthn Algorithms”
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 [email protected]<mailto:[email protected]> 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 <[email protected]<mailto:[email protected]>> On Behalf Of
Filip Skokan
Sent: Wednesday, March 27, 2019 2:17 PM
To: [email protected]<mailto:[email protected]>
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
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
