Re: [COSE] "P-256K" in draft-ietf-cose-webauthn-algorithms

[Mike Jones <[e-mail]>]

Thanks for the super-useful context, John.  Given that this isn’t a NIST curve, it seems that the “P-” naming is misleading and it’s unhelpful to introduce another name for the same thing.  I therefore plan to change the JOSE curve name to “secp256k1” in the next draft.  Yes, early implementations will need to change, but I suspect that we’d have to do this during IETF or IESG review anyway, so probably the earlier we make the change, the better.

                                                                -- Mike

From: COSE <[e-mail]> On Behalf Of John Mattsson
Sent: Friday, April 5, 2019 1:49 AM
To: Mike Jones <Michael.Jones=[e-mail]>; Filip Skokan <[e-mail]>; [e-mail]
Subject: Re: [COSE] "P-256K" in draft-ietf-cose-webauthn-algorithms

Hi,

Googling gives the following results:

"P-256K"             About 1 010 results   (where most hits are about 256K or memory)
"secp256k1"      About 97 700 results

I dislike "P-256K" in any IETF specification (JOSE, COSE, etc.) for two reasons:

1. The situation with 3 different SDOs giving different names to the same curves as summarized in Appendix A of RFC 8442 is bad enough. IETF does not need to make the situation worse by assigning a new name to secp256k1. Three columns in the table is more than enough.

2. If IETF need to assign a new name to secp256k1 I think "P-256K" is a bad choice as it gives the impression that it is a curve standardized by NIST (which it is not). I have already heard knowledgeable people thinking that it is a NIST curve. Given the recent IETF fury about ITU naming a protocol eTLS, I think IETF should refrain from this unless we get ok from NIST.

I have no objections to the curve itself or the name ES256K.

>what is the meaning of the “P” in the identifiers for the NIST curves “P-256”, etc.?

The P in NIST curves (P-256, P-384, etc.) means Prime
The K in NIST curves (K-233, K-283, etc.) means Koblitz
The B in NIST curves (B-233, B-283, etc.) means Binary

The r in SECG curves (secp256r1, secp384r1) means random
The k in SECG curves (secp256k1, sect233k1) means koblitz
The p in SECG curves (secp256r1, secp256k1) means prime
The t in SECG curves (sect233r1, sect233k1) means two?

John

From: COSE <[e-mail]<mailto:[e-mail]>> on behalf of Mike Jones <Michael.Jones=[e-mail]<mailto:Michael.Jones=[e-mail]>>
Date: Thursday, 4 April 2019 at 21:37
To: Filip Skokan <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [COSE] "P-256K" in draft-ietf-cose-webauthn-algorithms

More voices on the subject of what JOSE curve identifier should be used would be useful, as I want to publish an updated draft addressing review comments received to date.  To date, the input I’ve received is:

·         For “P-256K”:  Filip Skokan and Vladimir Dzhuvinov (off list)

·         For “secp256k1”:  Jim Schaad and John Mattsson

What do others think?

Also, as it might aid in thinking about the choices, what is the meaning of the “P” in the identifiers for the NIST curves “P-256”, etc.?

                                                       Thanks,
                                                       -- Mike

From: COSE <[e-mail]<mailto:[e-mail]>> On Behalf Of Filip Skokan
Sent: Wednesday, March 27, 2019 6:17 AM
To: [e-mail]<mailto:[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