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

From: Mike Jones <[email-masked]>
Date: Thu, 4 Apr 2019 19:36:57 +0000

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 <[email-masked]> On Behalf Of Filip Skokan
Sent: Wednesday, March 27, 2019 6:17 AM
To: [email-masked]
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

---

From: Filip Skokan <[email-masked]>
Date: Thu, 4 Apr 2019 22:20:56 +0200

IIRC Jim mentioned preferring just secp256k1 for COSE, but was indifferent
to what the JOSE naming should be.

S pozdravem,
*Filip Skokan*

On Thu, 4 Apr 2019 at 21:36, Mike Jones <[email-masked]> wrote:

> 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 <[email-masked]> *On Behalf Of * Filip Skokan
> *Sent:* Wednesday, March 27, 2019 6:17 AM
> *To:* [email-masked]
> *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
>
> 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*
>

---

From: Jim Schaad <[email-masked]>
Date: Thu, 4 Apr 2019 18:49:05 -0700

You have not received any input from me on what the JOSE curve identifier should be called.  I only care about the naming for the COSE curve identifier.

Jim

From: COSE <[email-masked]> On Behalf Of Mike Jones
Sent: Thursday, April 4, 2019 12:37 PM
To: Filip Skokan <[email-masked]>; [email-masked]
Subject: Re: [COSE] "P-256K" in draft-ietf-cose-webauthn-algorithms

What do others think?

                                                       Thanks,

                                                       -- Mike

From: COSE <[email-masked] <mailto:[email-masked]> > On Behalf Of Filip Skokan
Sent: Wednesday, March 27, 2019 6:17 AM
To: [email-masked] <mailto:[email-masked]> 
Subject: [COSE] "P-256K" in draft-ietf-cose-webauthn-algorithms

Hello,

- "P-256K"

Best,
Filip Skokan

---

From: John Mattsson <[email-masked]>
Date: Fri, 5 Apr 2019 08:49:06 +0000

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 <[email-masked]> on behalf of Mike Jones <Michael.Jones=[email-masked]>
Date: Thursday, 4 April 2019 at 21:37
To: Filip Skokan <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [COSE] "P-256K" in draft-ietf-cose-webauthn-algorithms

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

·         For “secp256k1”:  Jim Schaad and John Mattsson

What do others think?

                                                       Thanks,
                                                       -- Mike

Hello,

- "P-256K"

Best,
Filip Skokan

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 5 Apr 2019 09:56:07 +0100

On 05/04/2019 09:49, John Mattsson wrote:
> Given the recent IETF fury about ITU naming a protocol eTLS, 

That was ETSI not ITU.

There wasn't fury that I saw, more like irritation that ETSI
would clone an IETF protocol, damage a major feature (adding
highly imperfect forward secrecy ala draft-green) so as to
enable eavesdropping and then name the result confusingly.

Perhaps fury would've been more appropriate though, dealing
with such muppetry;-)

S.

---

From: John Mattsson <[email-masked]>
Date: Fri, 5 Apr 2019 09:10:05 +0000

-----Original Message-----
From: Stephen Farrell <[email-masked]>
Date: Friday, 5 April 2019 at 10:56
To: John Mattsson <[email-masked]>, Mike Jones <Michael.Jones=[email-masked]>, Filip Skokan <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [COSE] "P-256K" in draft-ietf-cose-webauthn-algorithms

    
    That was ETSI not ITU.

True, my fault.

I think it was good that IETF reacted, if ETSI wants to standardize something like this, they should call it something else.

And to clarify. The only similarity with P-256K is the confusion part. secp256k1 is not a bad curve in any way.

    S.

---

From: Mike Jones <[email-masked]>
Date: Fri, 5 Apr 2019 18:49:39 +0000

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

Hi,

John

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

What do others think?

                                                       Thanks,
                                                       -- Mike

From: COSE <[email-masked]<mailto:[email-masked]>> On Behalf Of Filip Skokan
Sent: Wednesday, March 27, 2019 6:17 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [COSE] "P-256K" in draft-ietf-cose-webauthn-algorithms

Hello,

- "P-256K"

Best,
Filip Skokan