RE: Changes required to add the NUMS curves to Web Cryptography API

Ryan,


1)      No, it wasn’t intentional on my part that you’d have to support all the NUMS curves in order to support ECDSA & ECDH, but I didn’t touch that language because I didn’t see a clear WG preference when I brought that specific point up on the list previously (see http://lists.w3.org/Archives/Public/public-webcrypto/2014Jun/0158.html).  I can go back and propose language changes for either option, depending on how the WG chooses to resolve bug #25985.

2)      I think you misinterpreted my reason for pulling the validation of namedCurve with RFC 5480, which has nothing to do with assigned OIDs (or lack thereof for the NUMS curves, which will get an OID arc prefix assigned anyway as the IETF drafts progress).  The way I read the phrase “an instance of the namedCurve ASN.1 type defined in RFC 5480” was “an instance of the namedCurve ASN.1 type [OBJECT IDENTIFIER] defined [in Section 2.1.1.1 Named Curve] in RFC 5480”.  I thought the reference here was to the specific list of curve OIDs contained in RFC 5480.  If all you want is to say it’s got to be the namedCurve CHOICE of ECParameters (which is an OID), I’m OK with that and the text can go back in, but maybe we can add some text to make it clear any OID is OK at that point.  This also goes for the SPKI section.

3)      I’m not a JSON/JWA person so I did just skip making any changes there since there’s no assigned crv value, but now that I see Section 6.2.1 of JWA I see you’re correct.  I can certainly put together proposed registrations and add them.  Also, now that you pointed this out there may be a fundamental problem here for the Curve25519 folks as the current Curve25519-related IETF draft (http://tools.ietf.org/html/draft-josefsson-tls-curve25519-05) defines a new ECPointFormat that contains only an x-coordinate (see Section 2.3 of that draft).  So the JWA MUST requirement for the y coordinate is going to conflict with usage of Curve25519 in JWA (as presently written) and thus have a problem converting to Web Crypto.

4)      As for whether all of the NUMS curves would be supported, my expectation is that the underlying math libraries would support all six curves (as our implementation does) but that individual protocols would choose a subset of the NUMS family that is appropriate to their needs.  This is the approach we have taken with our IETF drafts – all six curves are in the base CFRG-targeted draft but we’ve choses a subset of just two twisted Edwards curves for the TLS-targeted draft.  We made that choice based on engineering feedback from protocol implementers in the TLS community and a preference for the additional performance of the twisted Edwards curves over the reduced additional code required by the Weierstrass-form curves.  However, that preference is one of the issues I believe the TLS WG needs to discuss more fully.

--bal

From: Ryan Sleevi [mailto:sleevi@google.com]
Sent: Friday, July 11, 2014 5:24 PM
To: Brian LaMacchia
Cc: public-webcrypto@w3.org
Subject: Re: Changes required to add the NUMS curves to Web Cryptography API

Brian,

Thanks for writing this up. Several follow-ups, in the event you wish to clarify/make changes:

1) The proposed additions don't define what happens if an implementation does not support the NUMS curves. That is, as currently written, the spec currently assumes the three NIST curves (P-256, P-384, P-521) MUST be supported. Whether or not that's a good idea or not would likely be a separate, and useful, discussion, but at least that's the language at present.

Your modifications seem to continue that use of terminology, meaning that NUMS curves MUST be supported in order to support ECDSA/ECDH. Is that intentional?

2) You suggest removing the validation of namedCurve, because that limits support. However, that is NOT true, because namedCurve is an "OBJECT IDENTIFIER" type. While I realize the NUMS curves may not have OID ARCs assigned yet, it seems entirely reasonable that Microsoft may wish to allocate additional named curves.

The change, as you propose, would have the effect of requiring user agents to also implement support for the specifiedCurve ASN.1 choice, which is of the type SpecifiedECDomain, which RFC 5480 specifically recommends against.

This seems to be echo'd again in http://tools.ietf.org/html/rfc5480#section-2.1.1.1 , which merely notes that it's documenting several known object identifiers, and other publications can identify others. This would be internally consistent with your modifications to Step 8.

These same concerns are reflected in your SPKI import modifications.

3) It seems your modifications for JWK produce invalid JWK, which would seem to violate the basic contract of the API.

I understand that "crv" points have not yet been assigned, but it's a REQUIRED field for EC keys (See http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-31#section-6.2.1 ). Since this field MUST have a value, it seems like you would need to add registrations for that parameter, as per http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-31#section-7.6 , as part of the specs IANA considerations.



I think my biggest concern with this, individually, is that it highlights the issue that this is an all/nothing approach, which is why support for extensibility seems desirable. Further, it seems likely that implementations, including MSFT, may not wish to implement ALL of the NUMS curves. Are all 6 curves expected to always be present in implementations?



On Fri, Jul 11, 2014 at 4:28 PM, Brian LaMacchia <bal@microsoft.com<mailto:bal@microsoft.com>> wrote:
Dear fellow members of the W3C Web Cryptography WG,

Per the notice from the chair in Comment #39 of Bug #25839 (concerning the additional of new elliptic curves to the Web Cryptography standard), attached to this message are the changes to the main text of the spec necessary to add support for the NUMS curves for ECDSA and ECDH operations.  Per Ryan's request, I have provided textual additions based on the latest Editor's Draft (dated 16 June, 2014).  Changes are necessary to the ECDSA, ECDH and References sections.

Additionally, and as I note at the beginning of my list of changes, the W3C Web Cryptography API currently normatively references two ANSI specifications -- X9.62 and X9.62 -- for ECDSA and ECDH.  Neither ANSI specification is freely available.  Instead of referencing non-free specifications, it would be better to reference freely-available ECC specifications like RFC 6090 and FIPS 186-3.  As X9.62 and X9.63 are not freely available, I did not cross-check any of the references to either of those specs for extensibility (or lack thereof).

The list of required changes also highlights the places in the specification where extension of ECDSA and ECDH to other curves is currently blocked by the text.  Hopefully this itemized list will help with the resolution of Bug #25618 (concerning a formal way to extend the specification).

Finally, I would also call the WG's attention to the two Internet-Drafts that the NUMS group has recently submitted to the IETF and IRTF:

http://tools.ietf.org/id/draft-black-numscurves-01.txt, Elliptic Curve Cryptography (ECC) Nothing Up My Sleeve (NUMS) Curves and Curve Generation.  B. Black, J. Bos, C.Costello, P. Longa, M. Naerhig.

http://tools.ietf.org/id/draft-black-tls-numscurves-00.txt, Nothing Up My Sleeve (NUMS) Curves for Ephemeral Key Exchange in Transport Layer Security (TLS).  B. Black, T. Acar, M. Ray.

The NUMS group will be presenting both drafts at IETF-90 in Toronto.

Please let me know if you have any questions about any of the proposed changes,

                                        --bal