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

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 <secdispatch-bounces@ietf.org> On Behalf Of Phillip Hallam-Baker
Sent: Friday, June 8, 2018 12:03 PM
To: Mike Jones <Michael.Jones@microsoft.com>
Cc: secdispatch@ietf.org; Benjamin Kaduk <kaduk@mit.edu>
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 <Michael.Jones@microsoft.com<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.

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

                                                       -- Mike

From: hallam@gmail.com<mailto:hallam@gmail.com> <hallam@gmail.com<mailto:hallam@gmail.com>> On Behalf Of Phillip Hallam-Baker
Sent: Monday, June 4, 2018 12:15 PM
To: Mike Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>>
Cc: secdispatch@ietf.org<mailto:secdispatch@ietf.org>; Benjamin Kaduk <kaduk@mit.edu<mailto:kaduk@mit.edu>>
Subject: Re: [Secdispatch] Document that registers the SECG secp256k1 elliptic curve

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=40microsoft.com@dmarc.ietf.org<mailto:Michael.Jones=40microsoft.com@dmarc.ietf.org>> 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.

Thanks for your feedback.

                                                       -- Mike

_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.org<mailto:Secdispatch@ietf.org>
https://www.ietf.org/mailman/listinfo/secdispatch