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> 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
>
>
>
>
>
>
>
>