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

On Fri, Jul 11, 2014 at 6:16 PM, Brian LaMacchia <bal@microsoft.com> wrote:

>  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.
>
Yeah, this is why I've been egging for a separate spec, in part, because
I'm hoping someone ELSE will propose a modification for the language,
because I'm extremely unhappy with every attempt I've made at it so far.

For what it's worth, designs I've considered are the "registry" type
language used for algorithm normalization (i.e. that there's some registry
of curves, and an implementation can support on a per-curve basis, and if
they do support, it goes into a registry) and the "structured clone"
language used in HTML

Since I suspect you probably don't want me pointing to the WHATWG draft,
http://www.w3.org/html/wg/drafts/html/CR/infrastructure.html#safe-passing-of-structured-data
("if input is an object that another specification defines how to clone")

In order to go that last route, I suspect the entire processing of
parameters for SPKI/PKCS8/JWK has to be shifted around, such that the
curve-specific algorithms can be defined. For example, as you note below, a
Curve25519 may have a different key format than Import Key's Step 10 (which
defers to Section 2.2 of RFC 5480, which only the lists the
compressed/uncompressed SEC1 forms)

So fresh eyes on this problem are certainly welcome.


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

Yup. It was the intent that the contents are always an OID, and that the
WebCrypto spec would define the set of valid OIDs.

I've filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=26315 , so feel
free to chime in with any language modifications as needed.


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

Yup. I've been following it, and it's also why I would like to see
Curve25519 handled as a separate spec, because nailing down those aspects
are going to take time across multiple SDOs.

FWIW, this was discussed back in
http://lists.w3.org/Archives/Public/public-webcrypto/2014Feb/0049.html with
respect to ECDH.



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

Right, I certainly appreciate that protocols/applications will want to make
informed choices based on the needs of their users (hence the ongoing
debate about security considerations), I just wanted to confirm that from a
library implementation perspective, the idea was that a UA would always
make either all 6 curves available or no NUM curves available (mod the
discussion on #1 above as to whether 'no NUMS curves available' is a valid
answer)

Without getting into the merits of the answer, just wanted to make sure
that was intended.


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

Received on Saturday, 12 July 2014 01:37:12 UTC