Subject: [Secdispatch] Document that registers the SECG secp256k1 elliptic curve

From: Mike Jones <[email-masked]>
Date: Mon, 4 Jun 2018 19:12:02 +0000

This note is soliciting feedback on the best path for https://tools.ietf.org/html/draft-jones-webauthn-secp256k1-00 to become an RFC.  Its purpose is very specific and narrow:  It registers JOSE and COSE curve identifiers for the SECG secp256k1 elliptic curve and associated algorithm identifiers.   This is used by FIDO UAF, the W3C Verifiable Claims interest group, and several blockchain projects.  I want to get standard identifiers registered so these projects can use standards-based, rather than ad-hoc, cryptographic representations.  Given the widespread use of this curve and algorithm, I would like this spec to become an RFC so that the small integer values can be assigned for COSE, per the "Standards Action" requirement for the Label assignment in the registry policy at https://tools.ietf.org/html/rfc8152#section-16.2. I believe it's also very likely that some IETF specifications will end up using these registrations as well.

As background, I'd committed to the W3C Web Authentication (WebAuthn) working group and the FIDO Alliance to register all the algorithms used by their specifications that do not have current IANA registrations for JOSE and COSE.  https://tools.ietf.org/html/draft-jones-webauthn-cose-algorithms-01 started this process by registering additional RSA algorithms (with help from Jim Schaad, Sean Turner, and others).  The next step in this process is registering the SECG secp256k1 elliptic curve and associated algorithm identifiers.

Ben Kaduk suggested that I ask SecDispatch for input on the best path forward.  For instance, is anyone interested in reviewing the document or being the document shepherd?  I believe that Area Director sponsorship probably makes the best sense for this very targeted document but am open to other options.   I know that the W3C and the FIDO Alliance would appreciate having a path forward for these registrations.

Thanks for your feedback.

                                                       -- Mike

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 4 Jun 2018 15:15:08 -0400

If we are going to register algorithms, perhaps we could do all of them in
one doc including ASN.1 OIDS. These need not be new code points if already
specified but we should have one OID for IETF purposes per algorithm
wherever possible.

On Mon, Jun 4, 2018 at 3:12 PM, Mike Jones <
Michael.Jones=[email-masked]> wrote:

> This note is soliciting feedback on the best path for
> https://tools.ietf.org/html/draft-jones-webauthn-secp256k1-00 to become
> an RFC.  Its purpose is very specific and narrow:  It registers JOSE and
> COSE curve identifiers for the SECG secp256k1 elliptic curve and associated
> algorithm identifiers.   This is used by FIDO UAF, the W3C Verifiable
> Claims interest group, and several blockchain projects.  I want to get
> standard identifiers registered so these projects can use standards-based,
> rather than ad-hoc, cryptographic representations.  Given the widespread
> use of this curve and algorithm, I would like this spec to become an RFC so
> that the small integer values can be assigned for COSE, per the “Standards
> Action” requirement for the Label assignment in the registry policy at
> https://tools.ietf.org/html/rfc8152#section-16.2. I believe it’s also
> very likely that some IETF specifications will end up using these
> registrations as well.
>
>
>
> As background, I’d committed to the W3C Web Authentication (WebAuthn)
> working group and the FIDO Alliance to register all the algorithms used by
> their specifications that do not have current IANA registrations for JOSE
> and COSE.  https://tools.ietf.org/html/draft-jones-webauthn-cose-
> algorithms-01 started this process by registering additional RSA
> algorithms (with help from Jim Schaad, Sean Turner, and others).  The next
> step in this process is registering the SECG secp256k1 elliptic curve and
> associated algorithm identifiers.
>
>
>
> Ben Kaduk suggested that I ask SecDispatch for input on the best path
> forward.  For instance, is anyone interested in reviewing the document or
> being the document shepherd?  I believe that Area Director sponsorship
> probably makes the best sense for this very targeted document but am open
> to other options.   I know that the W3C and the FIDO Alliance would
> appreciate having a path forward for these registrations.
>
>
>
> _______________________________________________
> Secdispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch
>
>

---

From: John Menerick <[email-masked]>
Date: Mon, 04 Jun 2018 15:17:29 -0400

Agreed.

Warmly,

John Menerick
http://securesql.info

Sent from ProtonMail Mobile

On Mon, Jun 4, 2018 at 12:15, Phillip Hallam-Baker <[email-masked]> wrote:

> If we are going to register algorithms, perhaps we could do all of them in one doc including ASN.1 OIDS. These need not be new code points if already specified but we should have one OID for IETF purposes per algorithm wherever possible.
>
> On Mon, Jun 4, 2018 at 3:12 PM, Mike Jones <[Michael..Jones=[email-masked]](mailto:Michael.Jones=[email-masked])> wrote:
>
>> This note is soliciting feedback on the best path for https://tools.ietf.org/html/draft-jones-webauthn-secp256k1-00 to become an RFC.  Its purpose is very specific and narrow:  It registers JOSE and COSE curve identifiers for the SECG secp256k1 elliptic curve and associated algorithm identifiers.   This is used by FIDO UAF, the W3C Verifiable Claims interest group, and several blockchain projects.  I want to get standard identifiers registered so these projects can use standards-based, rather than ad-hoc, cryptographic representations.  Given the widespread use of this curve and algorithm, I would like this spec to become an RFC so that the small integer values can be assigned for COSE, per the "Standards Action" requirement for the Label assignment in the registry policy at https://tools.ietf.org/html/rfc8152#section-16.2. I believe it’s also very likely that some IETF specifications will end up using these registrations as well.
>>
>> As background, I’d committed to the W3C Web Authentication (WebAuthn) working group and the FIDO Alliance to register all the algorithms used by their specifications that do not have current IANA registrations for JOSE and COSE.  https://tools.ietf.org/html/draft-jones-webauthn-cose-algorithms-01 started this process by registering additional RSA algorithms (with help from Jim Schaad, Sean Turner, and others).  The next step in this process is registering the SECG secp256k1 elliptic curve and associated algorithm identifiers.
>>
>> ______________________________ _________________
>> Secdispatch mailing list
>> [email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Mon, 04 Jun 2018 20:43:19 -0400

Mike Jones <Michael.Jones=[email-masked]> wrote:
    > forward.  For instance, is anyone interested in reviewing the document
    > or being the document shepherd?  I believe that Area Director
    > sponsorship probably makes the best sense for this very targeted
    > document but am open to other options.   I know that the W3C and the
    > FIDO Alliance would appreciate having a path forward for these
    > registrations.

I'll volunteer to be the document shepherd.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Mike Jones <[email-masked]>
Date: Fri, 8 Jun 2018 17:43:15 +0000

Thanks for asking, Phillip.  I just took the time to look up whether there is already an OID registered for this curve and it turns out that there is.  See Section A.2.1 of http://www.secg.org/sec2-v2.pdf which specifies the OID 1.3.132.0.10 for secp256k1  (and also specifies OIDs for the other curves specified therein, such as 1.2.840.10045.3.1.7 for secp256r1).  Furthermore, RFC 5758 specifies the OID 1.2.840.10045.4.3.2 for ECDSA with SHA-256 in https://tools.ietf.org/html/rfc5758#section-3.2.

So I believe we’re already covered on the OID registrations.

                                                       -- Mike

From: [email-masked] <[email-masked]> On Behalf Of Phillip Hallam-Baker
Sent: Monday, June 4, 2018 12:15 PM
To: Mike Jones <[email-masked]>
Cc: [email-masked]; Benjamin Kaduk <[email-masked]>
Subject: Re: [Secdispatch] Document that registers the SECG secp256k1 elliptic curve

On Mon, Jun 4, 2018 at 3:12 PM, Mike Jones <Michael..Jones=[email-masked]<mailto:Michael.Jones=[email-masked]>> wrote:
This note is soliciting feedback on the best path for https://tools.ietf.org/html/draft-jones-webauthn-secp256k1-00 to become an RFC.  Its purpose is very specific and narrow:  It registers JOSE and COSE curve identifiers for the SECG secp256k1 elliptic curve and associated algorithm identifiers.   This is used by FIDO UAF, the W3C Verifiable Claims interest group, and several blockchain projects.  I want to get standard identifiers registered so these projects can use standards-based, rather than ad-hoc, cryptographic representations.  Given the widespread use of this curve and algorithm, I would like this spec to become an RFC so that the small integer values can be assigned for COSE, per the “Standards Action” requirement for the Label assignment in the registry policy at https://tools.ietf.org/html/rfc8152#section-16.2. I believe it’s also very likely that some IETF specifications will end up using these registrations as well.

                                                       -- Mike

_______________________________________________
Secdispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/secdispatch

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 8 Jun 2018 15:03:19 -0400

Could you point to those definitions in your draft so that we close the
circle?

There are two reasons for this. First, a lot of folk are going to use your
draft as cookie cutter for theirs and so there may not be an OID. But
equally importantly, we need to capture the fact that these two things are
the same. Otherwise, we are likely to end up having to write documents to
state that...

On Fri, Jun 8, 2018 at 1:43 PM, Mike Jones <[email-masked]>
wrote:

> Thanks for asking, Phillip.  I just took the time to look up whether there
> is already an OID registered for this curve and it turns out that there
> is.  See Section A.2.1 of http://www.secg.org/sec2-v2.pdf which specifies
> the OID 1.3.132.0.10 for secp256k1  (and also specifies OIDs for the other
> curves specified therein, such as 1.2.840.10045.3.1.7 for secp256r1).
> Furthermore, RFC 5758 specifies the OID 1.2.840.10045.4.3.2 for ECDSA with
> SHA-256 in https://tools.ietf.org/html/rfc5758#section-3.2.
>
>
>
> *From:* [email-masked] <[email-masked]> *On Behalf Of *Phillip
> Hallam-Baker
> *Sent:* Monday, June 4, 2018 12:15 PM
> *To:* Mike Jones <[email-masked]>
> *Cc:* [email-masked]; Benjamin Kaduk <[email-masked]>
> *Subject:* Re: [Secdispatch] Document that registers the SECG secp256k1
> elliptic curve
>
>
>
> On Mon, Jun 4, 2018 at 3:12 PM, Mike Jones <Michael..Jones=40microsoft.
> [email-masked] <Michael.Jones=[email-masked]>> wrote:
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 8 Jun 2018 19:23:32 +0000

Sure.  I was actually thinking of adding an appendix much like the one at https://tools.ietf.org/html/rfc7518#appendix-A cross-referencing the different identifiers.

                                                                -- Mike

From: Secdispatch <[email-masked]> On Behalf Of Phillip Hallam-Baker
Sent: Friday, June 8, 2018 12:03 PM
To: Mike Jones <[email-masked]>
Cc: [email-masked]; Benjamin Kaduk <[email-masked]>
Subject: Re: [Secdispatch] Document that registers the SECG secp256k1 elliptic curve

Could you point to those definitions in your draft so that we close the circle?

There are two reasons for this. First, a lot of folk are going to use your draft as cookie cutter for theirs and so there may not be an OID. But equally importantly, we need to capture the fact that these two things are the same. Otherwise, we are likely to end up having to write documents to state that...

On Fri, Jun 8, 2018 at 1:43 PM, Mike Jones <[email-masked]<mailto:Michael.Jones@microsoft..com>> wrote:
Thanks for asking, Phillip.  I just took the time to look up whether there is already an OID registered for this curve and it turns out that there is.  See Section A.2.1 of http://www.secg.org/sec2-v2.pdf which specifies the OID 1.3.132.0.10 for secp256k1  (and also specifies OIDs for the other curves specified therein, such as 1.2.840.10045.3.1.7 for secp256r1).  Furthermore, RFC 5758 specifies the OID 1.2.840.10045.4.3.2 for ECDSA with SHA-256 in https://tools.ietf.org/html/rfc5758#section-3.2.

                                                       -- Mike

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>> On Behalf Of Phillip Hallam-Baker
Sent: Monday, June 4, 2018 12:15 PM
To: Mike Jones <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Benjamin Kaduk <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Secdispatch] Document that registers the SECG secp256k1 elliptic curve

                                                       -- Mike