We could, but it would have to be marked as a feature at risk.

Judging by implementation status - especially within the cryptographic libraries that support the various UAs' ongoing implementations (NSS, CommonCrypto, and CNG - for Chrome/Firefox, Safari, and IE, respectively), it does not seem likely that this would meet the requirements of multiple inter-operable specifications at the time of REC.

Feature at risk seems reasonable, however I think the (apparent) demand for curve25519 would merit placing it in the spec. Also, there are a number of inter-operable implementations of curve25519, even if not in NSS/etc.

(In reply to Matt Corallo from comment #2)
> Feature at risk seems reasonable, however I think the (apparent) demand for
> curve25519 would merit placing it in the spec. Also, there are a number of
> inter-operable implementations of curve25519, even if not in NSS/etc.

Please note: Placing it in the spec is not any indication that it is or will be supported. As noted, none of these algorithms are mandatory to implement, for a variety of reasons that include both legal and political concerns.

Even the existing (specified) algorithms are features at risk - a lack of inter-operable implementations, or any implementation itself, is sufficient to result in it being removed from any final REC document.

I merely note this to set your expectation - the appearance of curve25519 would
1) Be no means an endorsement of the Web Cryptography WG that it is a good curve
2) Be no means an endorsement of the Web Cryptography WG that UAs SHOULD implement
3) Have a higher chance than normal of being removed from the specification in a few months, due to lack of implementation.

As such, specifying it now would likely do a greater disservice to developers than you intend, but it's certainly something we can discuss.

Indeed, I have no doubt it would still be unlikely to be implemented. But adding it to the spec now would force implementors to seriously consider adding it and (hopefully) consider it for its popularity and security properties.

I would object to adding only Curve25519 to the list of named curves if we're going to open up the NamedCurve list to curves beyond the NIST prime curves.  MSR recently published a paper [1] defining new Weierstrass curves that are faster than the corresponding NIST curves at the same security level and meet all the requirements of the SafeCurves project.  The Brainpool curves (which already have an IETF RFC) are also popular in non-NIST circles.  So, at a minimum, if we open up the NamedCurve to add Curve25519 then we should also add the Brainpool curves and the MSR curves.

[1] http://eprint.iacr.org/2014/130

(In reply to Brian LaMacchia from comment #5)
> I would object to adding only Curve25519 to the list of named curves if
> we're going to open up the NamedCurve list to curves beyond the NIST prime
> curves.  MSR recently published a paper [1] defining new Weierstrass curves
> that are faster than the corresponding NIST curves at the same security
> level and meet all the requirements of the SafeCurves project.  The
> Brainpool curves (which already have an IETF RFC) are also popular in
> non-NIST circles.  So, at a minimum, if we open up the NamedCurve to add
> Curve25519 then we should also add the Brainpool curves and the MSR curves.
> 
> [1] http://eprint.iacr.org/2014/130

The NamedCurve list has always been open. These would have all the same issues as I described in Comment 1 - that is, a requirement to have multi-vendor support (which even the Brainpool curves do not).

As such, their addition is highly likely to be short-lived.

An alternative is to separately spec, as described in Bug 25618, exactly what these curves are and how they behave, the operations they're valid for, etc.

As Matt pointed out in in Comment 0, there exists already large implementation support for Curve25519: http://ianix.com/pub/curve25519-deployment.html

Given the curve's favorable performance and security features [1], it seems like it should be added purely on technical merit.

If the argument against its addition to the dictionary is that support for it doesn't exist in "NSS, CommonCrypto, and CNG", then we should ask *why* isn't it supported in those libraries, and how difficult would it be to add support?

Given that many liberally licensed implementations of Curve25519 already exist (like libsodium [2]), I'm fairly certain the answer is: it is not at all difficult for these libraries to add support for it, and if they choose not to, it's likely for political reasons, not technical ones.

[1] http://cr.yp.to/ecdh/curve25519-20060209.pdf

[2] https://github.com/jedisct1/libsodium

(In reply to Greg Slepak from comment #7)
> As Matt pointed out in in Comment 0, there exists already large
> implementation support for Curve25519:
> http://ianix.com/pub/curve25519-deployment.html

I'm aware, but that's never been the consideration criteria. It's about what is available to User Agents.

The WG was chartered with the premise of leveraging the *existing* cryptographic capabilities in User Agents today - due to their TLS implementations - before beginning efforts to add whatever algorithm is in vogue at the time.

> 
> Given the curve's favorable performance and security features [1], it seems
> like it should be added purely on technical merit.
> 
> If the argument against its addition to the dictionary is that support for
> it doesn't exist in "NSS, CommonCrypto, and CNG", then we should ask *why*
> isn't it supported in those libraries, and how difficult would it be to add
> support?

And that's not a question for this WG. The fact remain that the support is not present in UAs.

> 
> Given that many liberally licensed implementations of Curve25519 already
> exist (like libsodium [2]), I'm fairly certain the answer is: it is not at
> all difficult for these libraries to add support for it, and if they choose
> not to, it's likely for political reasons, not technical ones.
> 
> [1] http://cr.yp.to/ecdh/curve25519-20060209.pdf
> 
> [2] https://github.com/jedisct1/libsodium

Yes, there is more than technical discussion here (although Curve25519 remains a highly charged technical discussion). The political issues are very much applicable for User Agents, particularly those that need to be available to users in a variety of countries and purposes.

While you can disagree with these, they are real issues that User Agent vendors have to deal with. Things like export controls and FIPS 140-2 remain issues for UAs and UA vendors.

Still, a reasonable path forward is to provide separate curves in a separate specification, which can then look at adding things like Curve25519, Poly1305, Salsa 20, or the BADA55 curves.

(In reply to Ryan Sleevi from comment #8)
> Yes, there is more than technical discussion here (although Curve25519
> remains a highly charged technical discussion). The political issues are
> very much applicable for User Agents, particularly those that need to be
> available to users in a variety of countries and purposes.
> 
> While you can disagree with these, they are real issues that User Agent
> vendors have to deal with. Things like export controls and FIPS 140-2 remain
> issues for UAs and UA vendors.
> 
> Still, a reasonable path forward is to provide separate curves in a separate
> specification, which can then look at adding things like Curve25519,
> Poly1305, Salsa 20, or the BADA55 curves.

Could you please explain what a separate specification would achieve?

Would it result in support for Curve25519 in Chrome and Firefox?

If not, then what's the point of a separate specification?

That then leads to a fork in the road. Get it? Fork? I made a funny! ;P

(In reply to Greg Slepak from comment #9)
> That then leads to a fork in the road. Get it? Fork? I made a funny! ;P

(Or Curve25519 implementations via browser extensions. That's just not as pretty though. :-\)

Sorry, just realized I had another question:

(In reply to Ryan Sleevi from comment #8)
> Yes, there is more than technical discussion here (although Curve25519
> remains a highly charged technical discussion). The political issues are
> very much applicable for User Agents, particularly those that need to be
> available to users in a variety of countries and purposes.
> 
> While you can disagree with these, they are real issues that User Agent
> vendors have to deal with. Things like export controls and FIPS 140-2 remain
> issues for UAs and UA vendors.

Could you elaborate on these issues?

Without researching them myself, it sounds like: "We don't want to recommend Curve25519 because it's secure."

Is that an accurate rephrasing? Is the job then of this working group to recommend insecure ciphers?

(In reply to Greg Slepak from comment #9)
> (In reply to Ryan Sleevi from comment #8)
> > Yes, there is more than technical discussion here (although Curve25519
> > remains a highly charged technical discussion). The political issues are
> > very much applicable for User Agents, particularly those that need to be
> > available to users in a variety of countries and purposes.
> > 
> > While you can disagree with these, they are real issues that User Agent
> > vendors have to deal with. Things like export controls and FIPS 140-2 remain
> > issues for UAs and UA vendors.
> > 
> > Still, a reasonable path forward is to provide separate curves in a separate
> > specification, which can then look at adding things like Curve25519,
> > Poly1305, Salsa 20, or the BADA55 curves.
> 
> Could you please explain what a separate specification would achieve?
> 
> Would it result in support for Curve25519 in Chrome and Firefox?

Including in this specification is no more or less likely, as noted already.

Each of the algorithms' specification is entirely independent, from the point of view of our REC track requirements.

That is, you can implement this spec with only support for SHA-1 *and* be fully spec compliant.

> 
> If not, then what's the point of a separate specification?

Separate specifications encourage separate discussion about the merits of individual algorithms, including recognizing the fact that UA acceptance is independent.

> 
> That then leads to a fork in the road. Get it? Fork? I made a funny! ;P

(In reply to Greg Slepak from comment #11)
> Sorry, just realized I had another question:
> 
> (In reply to Ryan Sleevi from comment #8)
> > Yes, there is more than technical discussion here (although Curve25519
> > remains a highly charged technical discussion). The political issues are
> > very much applicable for User Agents, particularly those that need to be
> > available to users in a variety of countries and purposes.
> > 
> > While you can disagree with these, they are real issues that User Agent
> > vendors have to deal with. Things like export controls and FIPS 140-2 remain
> > issues for UAs and UA vendors.
> 
> Could you elaborate on these issues?
> 
> Without researching them myself, it sounds like: "We don't want to recommend
> Curve25519 because it's secure."
> 
> Is that an accurate rephrasing? Is the job then of this working group to
> recommend insecure ciphers?

Please research them yourself before you begin leaping to conclusions and suggest ill-will to maliciousness on behalf of this WG.

There are a variety of algorithms that have concerns. For example, OCB, even if well-understood, has a set of non-technical concerns. A number of implementations ship work that only works one disregards the set of considerations (whether they be disregarding patent, jurisdictional, or export control law) that UAs must adhere to.

I think it's more important to remember that *none* of the algorithms in this specification are any statements regarding UA's behaviours. They are merely specifications about *how* the algorithm would behave, if implemented. The sampling of the algorithms was based primarily on what is widely available within UAs today, so that they can instead focus on technical discussion, without having to engage in these broader issues at this time.

For those that wish to engage in these debates, it would be helpful to approach as separate proposals, so that the specifications can proceed at independent paces.

(In reply to Ryan Sleevi from comment #12)
> Each of the algorithms' specification is entirely independent, from the
> point of view of our REC track requirements.
> 
> That is, you can implement this spec with only support for SHA-1 *and* be
> fully spec compliant.

Now I'm not sure we're talking about the same spec.

This is referring to the WebCryptoAPI, right?

http://www.w3.org/TR/WebCryptoAPI/ <-- this thing?

And you're saying that if I make a browser that only implements SHA1 then I can advertise it as supporting the WebCryptoAPI?

(In reply to Ryan Sleevi from comment #13)
> Please research them yourself before you begin leaping to conclusions and
> suggest ill-will to maliciousness on behalf of this WG.

I did.

66.7% of the NamedCurves in your spec (if we're talking about the same one) [1] are considered insecure [2], and that's only because DJB didn't list P-521 in his analysis (another NIST curve, probably also insecure, if there's a trend). Meaning that further analysis could indicate that all of the curves that you're currently listing in the spec are insecure.

[1] http://www.w3.org/TR/WebCryptoAPI/#dfn-NamedCurve

[2] http://safecurves.cr.yp.to/


> There are a variety of algorithms that have concerns. For example, OCB, even
> if well-understood, has a set of non-technical concerns. A number of
> implementations ship work that only works one disregards the set of
> considerations (whether they be disregarding patent, jurisdictional, or
> export control law) that UAs must adhere to.
> 
> I think it's more important to remember that *none* of the algorithms in
> this specification are any statements regarding UA's behaviours. They are
> merely specifications about *how* the algorithm would behave, if
> implemented. The sampling of the algorithms was based primarily on what is
> widely available within UAs today, so that they can instead focus on
> technical discussion, without having to engage in these broader issues at
> this time.

I don't think you answered my question here about what specific issues they are facing.

Also, I think your statements above are misleading. The spec says:

"The following values are recognized: "

And then proceeds to list three named curves, two of which are known to be unsafe, and the third probably as well.

In other words, you "do not recognize" any other curves. The language in the spec sounds very much like a recommendation of what should and should not be implemented.

If you disagree, then please make it clear in your spec that browsers can implement any curve that they want, and remove your list of non-recommendation-recommendations.


> For those that wish to engage in these debates, it would be helpful to
> approach as separate proposals, so that the specifications can proceed at
> independent paces.

I'm not sure I understand, could you give an example of what such a separate proposal would be called? "WebCryptoAPI (Secure Curve Version)"?

(In reply to Ryan Sleevi from comment #1)
> We could, but it would have to be marked as a feature at risk.
> 
> Judging by implementation status - especially within the cryptographic
> libraries that support the various UAs' ongoing implementations (NSS,
> CommonCrypto, and CNG - for Chrome/Firefox, Safari, and IE, respectively),
> it does not seem likely that this would meet the requirements of multiple
> inter-operable specifications at the time of REC.

When different CPU architectures have distinct implementations, you could count x86_64 impl. by person A and armv7 impl. by person B as distinct implementations.

(In reply to Ryan Sleevi from comment #8)
> While you can disagree with these, they are real issues that User Agent
> vendors have to deal with. Things like export controls and FIPS 140-2 remain
> issues for UAs and UA vendors.

What's the export control issue? Curve25519 appears to have been shipped as part of QUIC in Chrome and Opera and as part of AirPlay as well as some other stuff in Apple products.

As for FIPS, it seems wrong to limit the cryptographic primitives available world-wide just because a particular government doesn't want to use those primitives on their intranet.

From a security standpoint, would it be possible to provide a JS-implemented curve via script that the API can use? Assuming this does not compromise the security goals of the API, that would be a way to work around the issue of missing curves because anybody can supply its own curve along their crypto code.

(In reply to Florian Bender [fbender] from comment #16)
> From a security standpoint, would it be possible to provide a JS-implemented
> curve via script that the API can use? Assuming this does not compromise the
> security goals of the API, that would be a way to work around the issue of
> missing curves because anybody can supply its own curve along their crypto
> code.

Providing polyfills of algorithms is partially supported, as it's part of the JS runtime.

However, it's not fully possible to have a perfect polyfill with the current API. For example, if you unwrap a key, it's going to call the 'native' importKey, which as a result, will avoid any prototype overloading / method shadowing that you have done.

So "yes and no"

Just to be clear, I'm not proposing userscript-implemented algorithms but userscript-provided curves (where userscript == JS loaded from a website's server).

(In reply to Florian Bender [fbender] from comment #18)
> Just to be clear, I'm not proposing userscript-implemented algorithms but
> userscript-provided curves (where userscript == JS loaded from a website's
> server).

Why? It seems to me that the reason to have Curve25519 in the Web Crypto API would be to have it backed by hand-tuned CPU-specific implementations.

(In reply to Henri Sivonen from comment #15)
> When different CPU architectures have distinct implementations, you could
> count x86_64 impl. by person A and armv7 impl. by person B as distinct
> implementations.

There are zero *implementations*, let alone interoperable, in the cryptographic libraries used of *any* user agent implementing WebCrypto at present. All of the implementations have, at present, deferred crypto to the appropriate library.

As noted, the cryptographic libraries of two major implementors are presently tied to major OS releases. The two cryptographic libraries in use by the other implementors (NSS and OpenSSL) equally lack implementations of Curve25519.

There is no specification of Curve25519. The IETF has made talks of it, but has yet to actually make headway. It is simply "The code speaks for itself". While there are many implementations of Curve25519, for different platforms, they are all based on the same djb initial code and still re-use aspects of it.

It's popularity, unquestionable as it is - even within the organizations of at least two UAs - is not something at any level of maturity that the document can even place a normative reference on.

I disagree on the assertion that the x86_64 impl can be seen as interoperable with the armv7 impl on two grounds. The first is that the common implementation is not hand-rolled assembly but the common dbj C code. The second is that we've already seen past APIs that use a common code/library (eg: WebSQL -> SQLite), lacking definition or truly ground-up implementations, be rejected.

I don't oppose Curve25519 on crypto reasons; it's unquestionably desirable. But if we're going to talk about interoperability and well-defined algorithms, at present, this is lacking.

(In reply to Ryan Sleevi from comment #20)
> (In reply to Henri Sivonen from comment #15)
> > When different CPU architectures have distinct implementations, you could
> > count x86_64 impl. by person A and armv7 impl. by person B as distinct
> > implementations.
> 
> There are zero *implementations*, let alone interoperable, in the
> cryptographic libraries used of *any* user agent implementing WebCrypto at
> present. All of the implementations have, at present, deferred crypto to the
> appropriate library.
> 
> As noted, the cryptographic libraries of two major implementors are
> presently tied to major OS releases. The two cryptographic libraries in use
> by the other implementors (NSS and OpenSSL) equally lack implementations of
> Curve25519.
> 
> There is no specification of Curve25519. The IETF has made talks of it, but
> has yet to actually make headway. It is simply "The code speaks for itself".
> While there are many implementations of Curve25519, for different platforms,
> they are all based on the same djb initial code and still re-use aspects of
> it.
> 
> It's popularity, unquestionable as it is - even within the organizations of
> at least two UAs - is not something at any level of maturity that the
> document can even place a normative reference on.
> 
> I disagree on the assertion that the x86_64 impl can be seen as
> interoperable with the armv7 impl on two grounds. The first is that the
> common implementation is not hand-rolled assembly but the common dbj C code.
> The second is that we've already seen past APIs that use a common
> code/library (eg: WebSQL -> SQLite), lacking definition or truly ground-up
> implementations, be rejected.
> 
> I don't oppose Curve25519 on crypto reasons; it's unquestionably desirable.
> But if we're going to talk about interoperability and well-defined
> algorithms, at present, this is lacking.

As mentioned in another bug, Curve22519 is an example of an algorithm with real use-cases and actual demand from developers that can be registered (although it does lack a proper IETF RFC etc.) but may likely not be implemented by browsers (for whatever reason), but nonetheless should likely be registered and tested to be strictly fair with regards to the curve *and* the amount of demand for it. So "it's unlikely to be implemented" is not a good argument to not register it until test the interop to prove it isn't implemented. 

I am not arguing that we should test every possible curve and algorithm, but when multiple develoipers with use-cases want something tested and don't believe it's not implemented, then it probably is worthwhile for the WG to test it even if it's not implemented. 

Who knows - if demand keeps increasing, maybe browsers will implement?

(In reply to Harry Halpin from comment #21)
> I am not arguing that we should test every possible curve and algorithm, but
> when multiple develoipers with use-cases want something tested and don't
> believe it's not implemented, then it probably is worthwhile for the WG to
> test it even if it's not implemented. 
> 
> Who knows - if demand keeps increasing, maybe browsers will implement?

Harry,

Adding to the specification is *not* an act without costs. As you already note, this minimally requires developing testing suites. It requires user agents to integrate those. But it also requires normatively specifying something for which no normative references exist.

At this point, I would strongly prefer to keep it as an open bug, a future work item, for a separate specification, until we have a situation where user agents are clamoring for it and there's something with at least a modicum of maturity within the cryptographic community that we can actually reference for implementors to implement.

Simply saying "Oh, there's this curve" - without any description of it's requirements - is an untestable, unimplementable statement. Those do not belong in documents that are at the point of WGLC, and especially not towards CR. We shouldn't just be throwing everything in and seeing what sticks - that's not a good spec for any constituency.

(In reply to Ryan Sleevi from comment #22)

[chair hat] 

+1 on Ryan comment, adding an algorithm in the Web Crypto API costs. This algo was not part of our fist selection, currently there is no declared implementers ready to implement it. I don't have enough elements here to add this extra work to the editor's team.

(In reply to Ryan Sleevi from comment #22)
> (In reply to Harry Halpin from comment #21)
> > I am not arguing that we should test every possible curve and algorithm, but
> > when multiple develoipers with use-cases want something tested and don't
> > believe it's not implemented, then it probably is worthwhile for the WG to
> > test it even if it's not implemented. 
> > 
> > Who knows - if demand keeps increasing, maybe browsers will implement?
> 
> Harry,
> 
> Adding to the specification is *not* an act without costs. As you already
> note, this minimally requires developing testing suites. It requires user
> agents to integrate those. But it also requires normatively specifying
> something for which no normative references exist.
> 
> At this point, I would strongly prefer to keep it as an open bug, a future
> work item, for a separate specification, until we have a situation where
> user agents are clamoring for it and there's something with at least a
> modicum of maturity within the cryptographic community that we can actually
> reference for implementors to implement.
> 
> Simply saying "Oh, there's this curve" - without any description of it's
> requirements - is an untestable, unimplementable statement. Those do not
> belong in documents that are at the point of WGLC, and especially not
> towards CR. We shouldn't just be throwing everything in and seeing what
> sticks - that's not a good spec for any constituency.


No, we are not saying "Oh, there's this curve." We have real companies developing products that real users use (in this case, TextSecure) that require curve25519. If UA's don't want to implement it for whatever reason, that's the call of the companies that are implementing.

 However, *if* any algorithm can be specified in the manner that qualifies it as the same bar as other algorithms that have been registered, then to exclude it because a single person or company does not want it included would be unfair. The burden to add a curve to the list of registered algorithm is not high, *if* the person who raised the bugs is willing to draft the text to add to the spec and include a normative reference (and ideally code). Likewise, if the algorithm idetntifier is not recognized by a user agent, then the use of the algorithm identifier will quicly result in an error so the cost to the test-suite is fairly low.

In order to be fair, I suggest that Matt, Greg, or other people that want this curve please provide sample text that fulfills this:

http://www.w3.org/TR/2014/WD-WebCryptoAPI-20140325/#defining-an-algorithm

If the people that want this provide the text, then only if every implementer in the WG actually explicitly says they will not implement then the new algorithm should not be included in registered algorithms. 

Algorithms that a user provides the necessary text for can then be removed and put in another document (wiki) if there are not two interoperable implementations at the time of CR. 

In order to be fair, I would say the same process should apply to any new registered algorithms, including those brought up by BAL. We cannot arbitarily limit the inclusion of algorithms. We need clear rules and procedures, and I think the one above is fair. Algorithms should be registered if the proposer can provide text (including normative reference) and it *may* be implemented by the time we exit CR.

Just for reference, see-also https://code.google.com/p/end-to-end/issues/detail?id=64 and https://github.com/WhisperSystems/TextSecure-Browser/issues/41 for discussions surrounding implementing curve25519 in JS and the security questions around a JIT running crypto code.

(In reply to Harry Halpin from comment #24)
>  However, *if* any algorithm can be specified in the manner that qualifies
> it as the same bar as other algorithms that have been registered, then to
> exclude it because a single person or company does not want it included
> would be unfair. The burden to add a curve to the list of registered
> algorithm is not high, *if* the person who raised the bugs is willing to
> draft the text to add to the spec and include a normative reference (and
> ideally code). Likewise, if the algorithm idetntifier is not recognized by a
> user agent, then the use of the algorithm identifier will quicly result in
> an error so the cost to the test-suite is fairly low.
> 
> In order to be fair, I suggest that Matt, Greg, or other people that want
> this curve please provide sample text that fulfills this:
> 
> http://www.w3.org/TR/2014/WD-WebCryptoAPI-20140325/#defining-an-algorithm
> 
> If the people that want this provide the text, then only if every
> implementer in the WG actually explicitly says they will not implement then
> the new algorithm should not be included in registered algorithms. 
> 
> Algorithms that a user provides the necessary text for can then be removed
> and put in another document (wiki) if there are not two interoperable
> implementations at the time of CR. 
> 
> In order to be fair, I would say the same process should apply to any new
> registered algorithms, including those brought up by BAL. We cannot
> arbitarily limit the inclusion of algorithms. We need clear rules and
> procedures, and I think the one above is fair. Algorithms should be
> registered if the proposer can provide text (including normative reference)
> and it *may* be implemented by the time we exit CR.

Harry,

None of what you said conflicts with what I've said, except in on key, critical point.

This document is in the process of being finished. We have had a WGLC. We should NOT be adding to it at this time, especially without strong support from implementers AS WELL AS users.

Nothing prevents Curve25519 from being pursued as a separate document. We have made the same comments regarding other algorithms - SEED and GOST. The WG can then review such a document and decide whether or not to adopt it as REC track, and let that proceed through.

Continuing to argue for its inclusion in the spec only delays CR - after all, a significant change like adding Curve25519 (which again, despite there being implementations, lacks a good spec). Please note that Curve25519 is itself a curve that is NOT compatible with ECDSA NOR is negotiation the same as with ECDH (thus making it 'useless' from the perspective of the two APIs that *take* NamedCurve parameters).

These are all reasons why it's best addressed as a separate spec, that focuses just on the operations usable with it, and working through naming issues (eg: Do you use Ed25519 with ECDSA? Do you call the sign/verify some other thing?) is fruitful. But not today. Certainly not 8+ weeks ago when we went for WGLC.

Ryan, could you please address my earlier request and remove the list of curves from the document? Copying from Comment 14:

> And then proceeds to list three named curves, two of which are known to be unsafe, and the third probably as well.
> 
> In other words, you "do not recognize" any other curves. The language in the spec sounds very much like a recommendation of what should and should not be implemented.
> 
> If you disagree, then please make it clear in your spec that browsers can implement any curve that they want, and remove your list of non-recommendation-recommendations.

(In reply to Greg Slepak from comment #27)
> Ryan, could you please address my earlier request and remove the list of
> curves from the document? Copying from Comment 14:

This is not the appropriate bug for that discussion.

If you would like to have all elliptic curves removed from the spec, please file a new bug. Not specifying the curves is the same as removing them. Likewise, if you would like new curves added (other than this), please file a new bug.

(In reply to Ryan Sleevi from comment #26)
> (In reply to Harry Halpin from comment #24)
> >  [snip]
> > In order to be fair, I suggest that Matt, Greg, or other people that want
> > this curve please provide sample text that fulfills this:
> > 
> > http://www.w3.org/TR/2014/WD-WebCryptoAPI-20140325/#defining-an-algorithm
> >  [snip]
> Harry,
> 
> None of what you said conflicts with what I've said, except in on key,
> critical point.
> 
> This document is in the process of being finished. We have had a WGLC. We
> should NOT be adding to it at this time, especially without strong support
> from implementers AS WELL AS users.
> 
> Nothing prevents Curve25519 from being pursued as a separate document. We
> have made the same comments regarding other algorithms - SEED and GOST. The
> WG can then review such a document and decide whether or not to adopt it as
> REC track, and let that proceed through.
> 
> Continuing to argue for its inclusion in the spec only delays CR - after
> all, a significant change like adding Curve25519 (which again, despite there
> being implementations, lacks a good spec). Please note that Curve25519 is
> itself a curve that is NOT compatible with ECDSA NOR is negotiation the same
> as with ECDH (thus making it 'useless' from the perspective of the two APIs
> that *take* NamedCurve parameters).
> 
> These are all reasons why it's best addressed as a separate spec, that
> focuses just on the operations usable with it, and working through naming
> issues (eg: Do you use Ed25519 with ECDSA? Do you call the sign/verify some
> other thing?) is fruitful. But not today. Certainly not 8+ weeks ago when we
> went for WGLC.

OK, thank you Harry and Ryan for your comments about this.

Harry: thanks for the suggestion and the link. I will not be able to do this,
but maybe Matt (or someone else) could?

Ryan: What do you mean by separate spec? I've asked you this before but you
did not reply. A separate version of this spec, or a completely different
spec called "WebCryptoAPI (Secure Curve Version)"?

Also, what do you mean by "delays CR" (what is CR)? And regardless of whatever
CR means, why are you more concerned with delays than you are with the security
of the curves in the spec?

(In reply to Greg Slepak from comment #29)
> Ryan: What do you mean by separate spec? I've asked you this before but you
> did not reply. A separate version of this spec, or a completely different
> spec called "WebCryptoAPI (Secure Curve Version)"?

Neither.

A specification that defines your desired algorithm(s) and parameter(s).

> Also, what do you mean by "delays CR" (what is CR)? 

http://www.w3.org/2005/10/Process-20051014/cover.html#toc
http://www.w3.org/2005/10/Process-20051014/tr.html#Reports

> And regardless of
> whatever
> CR means, why are you more concerned with delays than you are with the
> security
> of the curves in the spec?

Please stop trying to hijack this bug. We're more than happy to address this feedback on the mailing list or a new bug.

(In reply to Ryan Sleevi from comment #30)
> (In reply to Greg Slepak from comment #29)
> > Ryan: What do you mean by separate spec? I've asked you this before but you
> > did not reply. A separate version of this spec, or a completely different
> > spec called "WebCryptoAPI (Secure Curve Version)"?
> 
> Neither.
> 
> A specification that defines your desired algorithm(s) and parameter(s).

Thanks, I assume that's the same thing that Harry was referring to with this link:

http://www.w3.org/TR/2014/WD-WebCryptoAPI-20140325/#defining-an-algorithm

Let me know if I'm mistaken.

> > Also, what do you mean by "delays CR" (what is CR)? 
> 
> http://www.w3.org/2005/10/Process-20051014/cover.html#toc
> http://www.w3.org/2005/10/Process-20051014/tr.html#Reports

Thanks!

> > And regardless of
> > whatever
> > CR means, why are you more concerned with delays than you are with the
> > security
> > of the curves in the spec?
> 
> Please stop trying to hijack this bug. We're more than happy to address this
> feedback on the mailing list or a new bug.

Sorry, I wasn't aware that I was hijacking. Done:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26080

(In reply to Ryan Sleevi from comment #20)
> (In reply to Henri Sivonen from comment #15)
> > When different CPU architectures have distinct implementations, you could
> > count x86_64 impl. by person A and armv7 impl. by person B as distinct
> > implementations.
> 
> There are zero *implementations*, let alone interoperable, in the
> cryptographic libraries used of *any* user agent implementing WebCrypto at
> present. All of the implementations have, at present, deferred crypto to the
> appropriate library.

The Process point I wanted to make is that in the case of per-ISA-optimized algorithms *one* library can *potentially* contain *two* independent interoperable implementations of a crypto algorithm.

Thus, moving from zero to two for Process purposes *might* be easier than it first seems.

> There is no specification of Curve25519.

Interesting. I thought the definitions in http://cr.yp.to/ecdh/curve25519-20060209.pdf and http://cr.yp.to/highspeed/naclcrypto-20090310.pdf were specific enough to serve as the specification basis for indepentent interoperable implementations, but I'm not really competent to assess if they are indeed specific enough.

> While there are many implementations of Curve25519, for different platforms,
> they are all based on the same djb initial code and still re-use aspects of
> it.

The situation with djb crypto that the best implementations for a given CPU tend to be in the Public Domain seems to mean that it doesn't make sense for anyone to ship something other than the best known implementation for a given CPU. If these all are derivatives of djb's code, they aren't independent.

I think in that case, if you can show that the specification is specific enough that independent implementations *can* be made, even if no one wants to ship those in real products at present, I think that should be enough to satisfy the purpose of the Process requirement, which is to demonstrate that the spec is specific enough.

http://nacl.cr.yp.to/valid.html claims that the latter of the two papers mentioned above contains independent implementations of the algorithms in NaCl (therefore, including Curve25519). The paper indeed contains Python code designated as an implementation by Matthew Dempsky. Is there a reason to believe that this implementation isn't independent enough to demonstrate independent implementability?

For an analogy, consider if all the major browsers implemented PNG using libpng. (I'm not sure if that's actually the case, but it easily could be.) Should PNG then not have been able to exit CR if independent implementability were demonstrated using a non-browser implementation? In many cases, using non-browser implementations to satisfy CR exit criteria is harmful, because non-browser implementations don't demonstrate whether the spec requires Web-incompatible behaviors. However, with crypto algorithms and bitmap image formats, the boundary of the units being tested is well-defined enough that it seems that using a non-browser implementation to demonstrate independent implementability is not a problem when the algorithm is new to the Web Platform.

> The second is that we've already seen past APIs that use a common
> code/library (eg: WebSQL -> SQLite), lacking definition or truly ground-up
> implementations, be rejected.

Indeed. However, "all the exact behaviors of a particular version of SQLite that Apple used" is *way* vaguer a set of behaviors than the behavior of a cryptographic primitive. Therefore, it seems that there is significantly less risk in determining that a cryptographic primitives is independently interoperable implementable even if all the implementations anyone would ship are dependent than determining that SQLite is. Also, even if it's the case the the above-mentioned papers don't describe Curve25519 well enough to constitute a "spec" (as noted, I'm not competent to evaluate whether this is the case), Curve25519 still seems way better defined than "all the exact behaviors of a particular version of SQLite that Apple used".

(In reply to Henri Sivonen from comment #32)
> (In reply to Ryan Sleevi from comment #20)
> > (In reply to Henri Sivonen from comment #15)
> > > When different CPU architectures have distinct implementations, you could
> > > count x86_64 impl. by person A and armv7 impl. by person B as distinct
> > > implementations.
> > 
> > There are zero *implementations*, let alone interoperable, in the
> > cryptographic libraries used of *any* user agent implementing WebCrypto at
> > present. All of the implementations have, at present, deferred crypto to the
> > appropriate library.
> 
> The Process point I wanted to make is that in the case of per-ISA-optimized
> algorithms *one* library can *potentially* contain *two* independent
> interoperable implementations of a crypto algorithm.
> 
> Thus, moving from zero to two for Process purposes *might* be easier than it
> first seems.
> 
> > There is no specification of Curve25519.
> 
> Interesting. I thought the definitions in
> http://cr.yp.to/ecdh/curve25519-20060209.pdf and
> http://cr.yp.to/highspeed/naclcrypto-20090310.pdf were specific enough to
> serve as the specification basis for indepentent interoperable
> implementations, but I'm not really competent to assess if they are indeed
> specific enough.
> 
> > While there are many implementations of Curve25519, for different platforms,
> > they are all based on the same djb initial code and still re-use aspects of
> > it.
> 
> The situation with djb crypto that the best implementations for a given CPU
> tend to be in the Public Domain seems to mean that it doesn't make sense for
> anyone to ship something other than the best known implementation for a
> given CPU. If these all are derivatives of djb's code, they aren't
> independent.
> 
> I think in that case, if you can show that the specification is specific
> enough that independent implementations *can* be made, even if no one wants
> to ship those in real products at present, I think that should be enough to
> satisfy the purpose of the Process requirement, which is to demonstrate that
> the spec is specific enough.
> 
> http://nacl.cr.yp.to/valid.html claims that the latter of the two papers
> mentioned above contains independent implementations of the algorithms in
> NaCl (therefore, including Curve25519). The paper indeed contains Python
> code designated as an implementation by Matthew Dempsky. Is there a reason
> to believe that this implementation isn't independent enough to demonstrate
> independent implementability?
> 
> For an analogy, consider if all the major browsers implemented PNG using
> libpng. (I'm not sure if that's actually the case, but it easily could be.)
> Should PNG then not have been able to exit CR if independent
> implementability were demonstrated using a non-browser implementation? In
> many cases, using non-browser implementations to satisfy CR exit criteria is
> harmful, because non-browser implementations don't demonstrate whether the
> spec requires Web-incompatible behaviors. However, with crypto algorithms
> and bitmap image formats, the boundary of the units being tested is
> well-defined enough that it seems that using a non-browser implementation to
> demonstrate independent implementability is not a problem when the algorithm
> is new to the Web Platform.
> 
> > The second is that we've already seen past APIs that use a common
> > code/library (eg: WebSQL -> SQLite), lacking definition or truly ground-up
> > implementations, be rejected.
> 
> Indeed. However, "all the exact behaviors of a particular version of SQLite
> that Apple used" is *way* vaguer a set of behaviors than the behavior of a
> cryptographic primitive. Therefore, it seems that there is significantly
> less risk in determining that a cryptographic primitives is independently
> interoperable implementable even if all the implementations anyone would
> ship are dependent than determining that SQLite is. Also, even if it's the
> case the the above-mentioned papers don't describe Curve25519 well enough to
> constitute a "spec" (as noted, I'm not competent to evaluate whether this is
> the case), Curve25519 still seems way better defined than "all the exact
> behaviors of a particular version of SQLite that Apple used".

Henri - this is a very interesting point as regards interoperability. I've emailed W3T. We'll have an answer back shortly. 

That being said, we need to figure out the before we go to CR how to address the problem of curve25519. Does Mozilla plan to support it?

(In reply to Ryan Sleevi from comment #26)
> (In reply to Harry Halpin from comment #24)
> >  However, *if* any algorithm can be specified in the manner that qualifies
> > it as the same bar as other algorithms that have been registered, then to
> > exclude it because a single person or company does not want it included
> > would be unfair. The burden to add a curve to the list of registered
> > algorithm is not high, *if* the person who raised the bugs is willing to
> > draft the text to add to the spec and include a normative reference (and
> > ideally code). Likewise, if the algorithm idetntifier is not recognized by a
> > user agent, then the use of the algorithm identifier will quicly result in
> > an error so the cost to the test-suite is fairly low.
> > 
> > In order to be fair, I suggest that Matt, Greg, or other people that want
> > this curve please provide sample text that fulfills this:
> > 
> > http://www.w3.org/TR/2014/WD-WebCryptoAPI-20140325/#defining-an-algorithm
> > 
> > If the people that want this provide the text, then only if every
> > implementer in the WG actually explicitly says they will not implement then
> > the new algorithm should not be included in registered algorithms. 
> > 
> > Algorithms that a user provides the necessary text for can then be removed
> > and put in another document (wiki) if there are not two interoperable
> > implementations at the time of CR. 
> > 
> > In order to be fair, I would say the same process should apply to any new
> > registered algorithms, including those brought up by BAL. We cannot
> > arbitarily limit the inclusion of algorithms. We need clear rules and
> > procedures, and I think the one above is fair. Algorithms should be
> > registered if the proposer can provide text (including normative reference)
> > and it *may* be implemented by the time we exit CR.
> 
> Harry,
> 
> None of what you said conflicts with what I've said, except in on key,
> critical point.
> 
> This document is in the process of being finished. We have had a WGLC. We
> should NOT be adding to it at this time, especially without strong support
> from implementers AS WELL AS users.

The WGLC is a reasonabvle time the time for the general public to request new algorithms, as it is the time for the general public to read the spec. Since the bug was filed beore the deadline, I don't see any process reasons why it can be ignored. 

The question over whether or not it can be well-specified is a question for implementers which is very valid. However, an IETF RFC is not required. Do you think DJB's papers are not enough for Google or anyone else to implement?

Any opinions on this from the rest of the implementers?

> 
> Nothing prevents Curve25519 from being pursued as a separate document. We
> have made the same comments regarding other algorithms - SEED and GOST. The
> WG can then review such a document and decide whether or not to adopt it as
> REC track, and let that proceed through.

Yes, but once we get to test-suite we need to have a clear list of algorithms. The question is whether or not Curve25519 are agreed. 

> 
> Continuing to argue for its inclusion in the spec only delays CR - after
> all, a significant change like adding Curve25519 (which again, despite there
> being implementations, lacks a good spec). Please note that Curve25519 is
> itself a curve that is NOT compatible with ECDSA NOR is negotiation the same
> as with ECDH (thus making it 'useless' from the perspective of the two APIs
> that *take* NamedCurve parameters).
> 
> These are all reasons why it's best addressed as a separate spec, that
> focuses just on the operations usable with it, and working through naming
> issues (eg: Do you use Ed25519 with ECDSA? Do you call the sign/verify some
> other thing?) is fruitful. But not today. Certainly not 8+ weeks ago when we
> went for WGLC.

(In reply to Greg Slepak from comment #29)
> (In reply to Ryan Sleevi from comment #26)
> > (In reply to Harry Halpin from comment #24)
> > >  [snip]
> > > In order to be fair, I suggest that Matt, Greg, or other people that want
> > > this curve please provide sample text that fulfills this:
> > > 
> > > http://www.w3.org/TR/2014/WD-WebCryptoAPI-20140325/#defining-an-algorithm
> > >  [snip]
> > Harry,
> > 
> > None of what you said conflicts with what I've said, except in on key,
> > critical point.
> > 
> > This document is in the process of being finished. We have had a WGLC. We
> > should NOT be adding to it at this time, especially without strong support
> > from implementers AS WELL AS users.
> > 
> > Nothing prevents Curve25519 from being pursued as a separate document. We
> > have made the same comments regarding other algorithms - SEED and GOST. The
> > WG can then review such a document and decide whether or not to adopt it as
> > REC track, and let that proceed through.
> > 
> > Continuing to argue for its inclusion in the spec only delays CR - after
> > all, a significant change like adding Curve25519 (which again, despite there
> > being implementations, lacks a good spec). Please note that Curve25519 is
> > itself a curve that is NOT compatible with ECDSA NOR is negotiation the same
> > as with ECDH (thus making it 'useless' from the perspective of the two APIs
> > that *take* NamedCurve parameters).
> > 
> > These are all reasons why it's best addressed as a separate spec, that
> > focuses just on the operations usable with it, and working through naming
> > issues (eg: Do you use Ed25519 with ECDSA? Do you call the sign/verify some
> > other thing?) is fruitful. But not today. Certainly not 8+ weeks ago when we
> > went for WGLC.
> 
> OK, thank you Harry and Ryan for your comments about this.
> 
> Harry: thanks for the suggestion and the link. I will not be able to do this,
> but maybe Matt (or someone else) could?

@Matt - can you specify the algorithm given the format in the link? 

i.e. 
http://www.w3.org/TR/2014/WD-WebCryptoAPI-20140325/#defining-an-algorithm

If needed, you may wish to pursue a separate document for the reasons noted by Ryan. If you have any questions, just ask.

Until we get a very clear proposal in terms of textual changes (either as changes to the existing spec or as a new document), it will be hard to close this bug fairly. 

Ryan is obviously busy with many other bugs, so I think it's very fair to ask the developers who need this to define it.

> 
> Ryan: What do you mean by separate spec? I've asked you this before but you
> did not reply. A separate version of this spec, or a completely different
> spec called "WebCryptoAPI (Secure Curve Version)"?
> 
> Also, what do you mean by "delays CR" (what is CR)? And regardless of
> whatever
> CR means, why are you more concerned with delays than you are with the
> security
> of the curves in the spec?

(In reply to Harry Halpin from comment #35)
> (In reply to Greg Slepak from comment #29)
> > (In reply to Ryan Sleevi from comment #26)
> > > (In reply to Harry Halpin from comment #24)
> > > >  [snip]
> > > > In order to be fair, I suggest that Matt, Greg, or other people that want
> > > > this curve please provide sample text that fulfills this:
> > > > 
> > > > http://www.w3.org/TR/2014/WD-WebCryptoAPI-20140325/#defining-an-algorithm
> > > >  [snip]
> > > Harry,
> > > 
> > > None of what you said conflicts with what I've said, except in on key,
> > > critical point.
> > > 
> > > This document is in the process of being finished. We have had a WGLC. We
> > > should NOT be adding to it at this time, especially without strong support
> > > from implementers AS WELL AS users.
> > > 
> > > Nothing prevents Curve25519 from being pursued as a separate document. We
> > > have made the same comments regarding other algorithms - SEED and GOST. The
> > > WG can then review such a document and decide whether or not to adopt it as
> > > REC track, and let that proceed through.
> > > 
> > > Continuing to argue for its inclusion in the spec only delays CR - after
> > > all, a significant change like adding Curve25519 (which again, despite there
> > > being implementations, lacks a good spec). Please note that Curve25519 is
> > > itself a curve that is NOT compatible with ECDSA NOR is negotiation the same
> > > as with ECDH (thus making it 'useless' from the perspective of the two APIs
> > > that *take* NamedCurve parameters).
> > > 
> > > These are all reasons why it's best addressed as a separate spec, that
> > > focuses just on the operations usable with it, and working through naming
> > > issues (eg: Do you use Ed25519 with ECDSA? Do you call the sign/verify some
> > > other thing?) is fruitful. But not today. Certainly not 8+ weeks ago when we
> > > went for WGLC.
> > 
> > OK, thank you Harry and Ryan for your comments about this.
> > 
> > Harry: thanks for the suggestion and the link. I will not be able to do this,
> > but maybe Matt (or someone else) could?
> 
> @Matt - can you specify the algorithm given the format in the link? 
> 
> i.e. 
> http://www.w3.org/TR/2014/WD-WebCryptoAPI-20140325/#defining-an-algorithm
> 
> If needed, you may wish to pursue a separate document for the reasons noted
> by Ryan. If you have any questions, just ask.
> 
> Until we get a very clear proposal in terms of textual changes (either as
> changes to the existing spec or as a new document), it will be hard to close
> this bug fairly. 
> 
> Ryan is obviously busy with many other bugs, so I think it's very fair to
> ask the developers who need this to define it.
> 

Harry,

I (and others here at MSR) would be happy to supply the relevant text for the MSR curves (we've started calling them the NUMS curves, short for "nothing up my sleeves").  Would you prefer raw text or diffs on the existing Overview-WebCryptoAPI.xml file?

(In reply to Brian LaMacchia from comment #36)
> Harry,
> 
> I (and others here at MSR) would be happy to supply the relevant text for
> the MSR curves (we've started calling them the NUMS curves, short for
> "nothing up my sleeves").  Would you prefer raw text or diffs on the
> existing Overview-WebCryptoAPI.xml file?

While I realize the question was addressed to Harry:

As editor, proposed texts is preferred over diffs, if only because there are still 39 open bugs, and diffs will skew.

As an implementer, we would prefer to see support for / description of NUMS curves as a separate, algorithm-specific specification. To the extent that may not be possible (eg: as currently, all named curves are normatively REQUIRED for an implementation to support ECDSA/ECDH), resolving Bug 25618 would block such effort. Microsoft taking the effort to provide such a specification, and noting the exact points at which they cannot, would go a significant way to resolving the concerns of Bug 25618.

From a process point, such curves invariably represent "substantive changes" ( http://www.w3.org/2005/10/Process-20051014/tr.html#substantive-change ) and would no doubt cause a restart of either the LC process or another WG draft. This seems highly undesirable, according to the WG schedule/timelines.

(In reply to Brian LaMacchia from comment #36)
> (In reply to Harry Halpin from comment #35)
> > (In reply to Greg Slepak from comment #29)
> > > (In reply to Ryan Sleevi from comment #26)
> > > > (In reply to Harry Halpin from comment #24)
> > > > >  [snip]
> > > > > In order to be fair, I suggest that Matt, Greg, or other people that want
> > > > > this curve please provide sample text that fulfills this:
> > > > > 
> > > > > http://www.w3.org/TR/2014/WD-WebCryptoAPI-20140325/#defining-an-algorithm
> > > > >  [snip]
> > > > Harry,
> > > > 
> > > > None of what you said conflicts with what I've said, except in on key,
> > > > critical point.
> > > > 
> > > > This document is in the process of being finished. We have had a WGLC. We
> > > > should NOT be adding to it at this time, especially without strong support
> > > > from implementers AS WELL AS users.
> > > > 
> > > > Nothing prevents Curve25519 from being pursued as a separate document. We
> > > > have made the same comments regarding other algorithms - SEED and GOST. The
> > > > WG can then review such a document and decide whether or not to adopt it as
> > > > REC track, and let that proceed through.
> > > > 
> > > > Continuing to argue for its inclusion in the spec only delays CR - after
> > > > all, a significant change like adding Curve25519 (which again, despite there
> > > > being implementations, lacks a good spec). Please note that Curve25519 is
> > > > itself a curve that is NOT compatible with ECDSA NOR is negotiation the same
> > > > as with ECDH (thus making it 'useless' from the perspective of the two APIs
> > > > that *take* NamedCurve parameters).
> > > > 
> > > > These are all reasons why it's best addressed as a separate spec, that
> > > > focuses just on the operations usable with it, and working through naming
> > > > issues (eg: Do you use Ed25519 with ECDSA? Do you call the sign/verify some
> > > > other thing?) is fruitful. But not today. Certainly not 8+ weeks ago when we
> > > > went for WGLC.
> > > 
> > > OK, thank you Harry and Ryan for your comments about this.
> > > 
> > > Harry: thanks for the suggestion and the link. I will not be able to do this,
> > > but maybe Matt (or someone else) could?
> > 
> > @Matt - can you specify the algorithm given the format in the link? 
> > 
> > i.e. 
> > http://www.w3.org/TR/2014/WD-WebCryptoAPI-20140325/#defining-an-algorithm
> > 
> > If needed, you may wish to pursue a separate document for the reasons noted
> > by Ryan. If you have any questions, just ask.
> > 
> > Until we get a very clear proposal in terms of textual changes (either as
> > changes to the existing spec or as a new document), it will be hard to close
> > this bug fairly. 
> > 
> > Ryan is obviously busy with many other bugs, so I think it's very fair to
> > ask the developers who need this to define it.
> > 
> 
> Harry,
> 
> I (and others here at MSR) would be happy to supply the relevant text for
> the MSR curves (we've started calling them the NUMS curves, short for
> "nothing up my sleeves").  Would you prefer raw text or diffs on the
> existing Overview-WebCryptoAPI.xml file?


Brian,

Two questions:

1) Does the MSR curves include Curve25519 for DH? 
2) Do those curves require any additional work (key formats etc.) that make them more complex than the rest of the algorithms already registered? 

I've had a substantial discussion about whether these curves should be included as registered algorithms in the "main spec" text of the API or as a separate extension spec. While Ryan would prefer an extension spec, I'm neutral. Any opinion?

Regardless, could you do the text of those diffs or an extension spec within about two weeks?

Matt, Greg, Brian, Henri,

The team (chair/staff/editors) made a status this week on Web Crypto API Last Call and discussed a way to move forward on this bug [1]. 

There are two algorithms requested here curve 25519 (requested by users) and MRS curve (requested by one implementer). If we want to have them as part of this Working Group deliverable, we need to have some contribution, describing those algorithms. 

Provided the low support from implementers to those algorithms (as of today, only microsoft is promoting MRS curve) this makes that features at risk (meaning that they may disappear from the specification when we will move to Proposed Recommendation). The team thought that it would be more efficient to have those algorithms described in separate specifications. Those specifications, complementing the Web Crypto API would aim to be recommendations, following the W3C recommendation process. By choosing to have separate document we make sure that (1) we do not delay the Web Crypto API and (2) have fruitful and fair discussions around the algorithms description. Recommendations status relies on the fact that WG is able to demonstrate at least 2 implementations. As such, if any of those separate specification becomes a recommendation, we will manage to re-integrate it into the next version of the Web Crypto API. 

Based on this recommended plan, how to move forward on this bug ?
We can associate those additional specifications to our current last call track, if (1) those additional specifications are available in a timeframe suitable to our Last Call milestones and (2) the additional specifications provided are agreed by the WG. As such, could you please provide the WG with a description of those algorithms as a separate specification, as a complement to the Web Crypto API. You can name it 'Web Crypto API - Curve 25519 algorithm' and 'Web Crypto API - MRS curve algorithm'. please make sure that the description is compatible with the current vocabulary and semantic of the main specification 'Web Crypto API'. 
 
We expect the additional specifications by the 11th of July (remember, we are in Last Call process and are targeting to solve bugs and get out of it asap). 

My take is that the workload will be split as follow : 
- MRS curve -> editor may be brian
- curve 25519 -> editor may be matt (or henri ?)

Thanks for confirming that you are volunteering to write that contribution and can deliver it on time. 

Virginie
chair of Web Crypto WG

[1] http://lists.w3.org/Archives/Public/public-webcrypto/2014Jun/0151.html

Yea, I will do my best to provide such a document in the specified timeframe.

(In reply to virginie.galindo from comment #39)
> Matt, Greg, Brian, Henri,
> 
> The team (chair/staff/editors) made a status this week on Web Crypto API
> Last Call and discussed a way to move forward on this bug [1]. 
> 
> There are two algorithms requested here curve 25519 (requested by users) and
> MRS curve (requested by one implementer). If we want to have them as part of
> this Working Group deliverable, we need to have some contribution,
> describing those algorithms. 
> 
> Provided the low support from implementers to those algorithms (as of today,
> only microsoft is promoting MRS curve) this makes that features at risk
> (meaning that they may disappear from the specification when we will move to
> Proposed Recommendation). The team thought that it would be more efficient
> to have those algorithms described in separate specifications. Those
> specifications, complementing the Web Crypto API would aim to be
> recommendations, following the W3C recommendation process. By choosing to
> have separate document we make sure that (1) we do not delay the Web Crypto
> API and (2) have fruitful and fair discussions around the algorithms
> description. Recommendations status relies on the fact that WG is able to
> demonstrate at least 2 implementations. As such, if any of those separate
> specification becomes a recommendation, we will manage to re-integrate it
> into the next version of the Web Crypto API. 
> 
> Based on this recommended plan, how to move forward on this bug ?
> We can associate those additional specifications to our current last call
> track, if (1) those additional specifications are available in a timeframe
> suitable to our Last Call milestones and (2) the additional specifications
> provided are agreed by the WG. As such, could you please provide the WG with
> a description of those algorithms as a separate specification, as a
> complement to the Web Crypto API. You can name it 'Web Crypto API - Curve
> 25519 algorithm' and 'Web Crypto API - MRS curve algorithm'. please make
> sure that the description is compatible with the current vocabulary and
> semantic of the main specification 'Web Crypto API'. 
>  
> We expect the additional specifications by the 11th of July (remember, we
> are in Last Call process and are targeting to solve bugs and get out of it
> asap). 
> 
> My take is that the workload will be split as follow : 
> - MRS curve -> editor may be brian
> - curve 25519 -> editor may be matt (or henri ?)
> 
> Thanks for confirming that you are volunteering to write that contribution
> and can deliver it on time. 
> 
> Virginie
> chair of Web Crypto WG
> 
> [1] http://lists.w3.org/Archives/Public/public-webcrypto/2014Jun/0151.html

Hello Virginie,

I will commit to providing text for at least the MSR curves, but we (Microsoft) disagree with your suggestion that the bug be resolved via extension specifications.  Our consensus opinion is that it would be much better if we try to resolve this bug with changes to the main text.  As has been pointed out previously, the current text in the draft implies that in order to implement ECDSA and ECDH, one must implement all of the NIST Prime curves, and the text in sections 18.8 and 18.9 must be modified to permit anything other than the NIST curves to be used.  So main text edits are required to resolve this bug in any way other than “won’t fix”.

Given all algorithms are optional, we think that we should put all of these non-NIST curves into the main text and then choose one of the two following positions:

1)	All curves are optional to implement, including the NIST curves
2)	NIST P-256 and NIST P-384 are mandatory-to-implement if you implement ECDSA and/or ECDH, and everything else is optional.  (I would not argue for P-521 to be mandatory as it’s just not used in practice anywhere.)

If we following this procedure, then additional curves may be added to the list of named curves and we will just have to change the NIST curve-only text.  We can add Curve25519, the MSR curves and even the Brainpool curves (as I pointed out in my original bug comment) as a group to accommodate the various requests that have been received.  We think that’s the best way forward.  

Assuming you agree with this revised proposal, I’ll commit to being point person for the MSR curves and collaborating with Matt and Henri on a combined set of edits to permit non-NIST curves to be used in Web Crypto.

Thanks,

--bal

(In reply to Brian LaMacchia from comment #41)
> (In reply to virginie.galindo from comment #39)

> Hello Virginie,
> 
> I will commit to providing text for at least the MSR curves, but we
> (Microsoft) disagree with your suggestion that the bug be resolved via
> extension specifications.  Our consensus opinion is that it would be much
> better if we try to resolve this bug with changes to the main text.  As has
> been pointed out previously, the current text in the draft implies that in
> order to implement ECDSA and ECDH, one must implement all of the NIST Prime
> curves, and the text in sections 18.8 and 18.9 must be modified to permit
> anything other than the NIST curves to be used.  So main text edits are
> required to resolve this bug in any way other than “won’t fix”.
> 
> Given all algorithms are optional, we think that we should put all of these
> non-NIST curves into the main text and then choose one of the two following
> positions:
> 
> 1)	All curves are optional to implement, including the NIST curves
> 2)	NIST P-256 and NIST P-384 are mandatory-to-implement if you implement
> ECDSA and/or ECDH, and everything else is optional.  (I would not argue for
> P-521 to be mandatory as it’s just not used in practice anywhere.)
> 
> If we following this procedure, then additional curves may be added to the
> list of named curves and we will just have to change the NIST curve-only
> text.  We can add Curve25519, the MSR curves and even the Brainpool curves
> (as I pointed out in my original bug comment) as a group to accommodate the
> various requests that have been received.  We think that’s the best way
> forward.  
> 
> Assuming you agree with this revised proposal, I’ll commit to being point
> person for the MSR curves and collaborating with Matt and Henri on a
> combined set of edits to permit non-NIST curves to be used in Web Crypto.
> 
> Thanks,
> 
> --bal

Brian,

the suggestion to resolve that bug, designed by the team made of chair, editors and W3C staff, was the result of a balance between having all chances to progress on the integration of the algorithms description, and not delaying the Web Crypto API progress to exit Last Call. If you feel more comfortable with writing changes to the main specification, I can not prevent you to do so. 

Note that as this change to the main specification will be a substantial change. As such it will have to be submitted to WG decision. 

So here is the plan : 
- all contributions related to 3 new algorithm descriptions are expected by the 11th of July (whatever is the format)
- the WG will have a conference call on Monday 21st of July @20 UTC, our usual time. This will allow WG participants to read your contributions and asks questions, makes comments in bugzilla or public mailing list. 
- During this call on 21st of July, the WG will be asked to formally vote, to either integrate your contribution in the main specification, as received on the 11th of July (with the option of going back or not to another Last Call round), or split it into separate specifications which will aim to have its own lifecycle to become a recommendation (aka following W3C process in the Web Crypto WG). 

As chair, I would like this Web Crypto API to move forward, that is why I am maintaining strict deadline in the decision making (aka 11th of July text provided, 21st of July vote based on the 11th of July text).

Regards
Virginie
Chair of the Web Crypto WG

Contribution from Microsoft related to changes to the main text of the spec necessary to add support for the NUMS curves for ECDSA and ECDH operations is available here :  
http://lists.w3.org/Archives/Public/public-webcrypto/2014Jul/0041.html

Hi,

Has this issue reached resolution?

I know that TextSecure (which Matt Corallo and I work on) uses Curve25519, and many other projects are either using it (SSH [1], Tor [2], CryptoCat [3], miniLock [4]); or have expressed interest (PGP [5], OTR [6], TLS [7]).

I suspect Javascript will not be used much for older network-layer protocols like IPsec, where NIST curves have found favor.  Rather, Javascript will be used for newer protocols where people are choosing Curve25519 due to its better performance.

It would be unfortunate if this API omits the curve that most new projects are choosing.

[1] http://git.libssh.org/projects/libssh.git/tree/doc/curve25519-sha256@libssh.org.txt
[2] https://gitweb.torproject.org/torspec.git?a=blob_plain;hb=HEAD;f=tor-spec.txt
[3] https://github.com/cryptocat/cryptocat/wiki/Multiparty-Protocol-Specification
[4] http://minilock.io/
[5] https://moderncrypto.org/mail-archive/curves/2014/000195.html
[6] https://lists.cypherpunks.ca/pipermail/otr-dev/2014-July/002183.html
[7] https://datatracker.ietf.org/doc/draft-josefsson-tls-curve25519/

(In reply to webcrypto from comment #44)
> Hi,
> 
> Has this issue reached resolution?

While I realize it's a lot to read, no, there is no resolution on this, because there's a number of outstanding issues:

- Suitable normative reference (TLS is still debating this)
- Suitable key format reference (TLS is still debating this)
- Suitable proposal (in a separate spec) by someone motivated for support for this
  - Which also makes sure to update ECDH / ECDSA descriptions to be explicit about what Curve25519 is and is not suitable for

Sadly, Curve25519 lacks these, despite having an unquestionable element of 'common sense' attached to it. That said, common sense does not a good spec make, so these issues need to be resolved first.

(In reply to Ryan Sleevi from comment #45)
> (In reply to webcrypto from comment #44)
> > Hi,
> > 
> > Has this issue reached resolution?
> 
> While I realize it's a lot to read, no, there is no resolution on this,
> because there's a number of outstanding issues:
> 
> - Suitable normative reference (TLS is still debating this)
> - Suitable key format reference (TLS is still debating this)

Is Dan Bernstein's paper from PKC 2006 not a sufficient reference?  It's available at stable URLs in a couple places, contains a detailed algorithm description, and is widely cited as "the" curve25519 paper:

http://cr.yp.to/ecdh/curve25519-20060209.pdf
http://www.iacr.org/cryptodb/archive/2006/PKC/3351/3351.pdf

There are multiple independent implementations.  I've never heard of interop problems.


> - Suitable proposal (in a separate spec) by someone motivated for support
> for this
>   - Which also makes sure to update ECDH / ECDSA descriptions to be explicit
> about what Curve25519 is and is not suitable for

Has no-one provided these?  I'd be happy to do so, though it might take a few weeks, and I believe you're on a tight schedule?

Whether this makes sense in the core document or a separate one I don't know.

But if there are issues with including Curve25519 in WebCrypto's notion of a "curve", as some comments in this bug imply, it may be worth working this out before the core documents issue, in case this reflects limitations of WebCrypto.

Trevor

(In reply to Trevor Perrin from comment #46)
> (In reply to Ryan Sleevi from comment #45)
> > - Suitable normative reference (TLS is still debating this)
> > - Suitable key format reference (TLS is still debating this)
> 
> Is Dan Bernstein's paper from PKC 2006 not a sufficient reference?  It's
> available at stable URLs in a couple places, contains a detailed algorithm
> description, and is widely cited as "the" curve25519 paper:
> 
> http://cr.yp.to/ecdh/curve25519-20060209.pdf
> http://www.iacr.org/cryptodb/archive/2006/PKC/3351/3351.pdf
> 
> There are multiple independent implementations.  I've never heard of interop
> problems.

Nope! It's not, that's part of the delay.

For example, how do you represent such a key in a subjectPublicKeyInfo? Is it a OID for a NamedCurve (which is the only format that Web Crypto supports) on an id-ecPublicKey AlgorithmInfo? Is it something else?

What about for PKCS#8?

Should it work with JWK? If so, who is responsible for the JWA registration, and how does that relate with JWA's choice to represent points (see https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms - JOSE knows that the format won't work with Curve25519 as written)


> > - Suitable proposal (in a separate spec) by someone motivated for support
> > for this
> >   - Which also makes sure to update ECDH / ECDSA descriptions to be explicit
> > about what Curve25519 is and is not suitable for
> 
> Has no-one provided these?  I'd be happy to do so, though it might take a
> few weeks, and I believe you're on a tight schedule?

The schedule is irrelevant, because it wouldn't be part of the "main" spec.

That is, it's best to think of the "main spec" as a set of API definitions (the IDL bindings), and then a set of otherwise-independent algorithm specifications. The fact that this isn't obvious today is, in part, due to Bug 25618 not yet being resolved suitably (see the discussion on the NUMS curves - http://lists.w3.org/Archives/Public/public-webcrypto/2014Jul/0041.html )

> 
> Whether this makes sense in the core document or a separate one I don't know.
> 
> But if there are issues with including Curve25519 in WebCrypto's notion of a
> "curve", as some comments in this bug imply, it may be worth working this
> out before the core documents issue, in case this reflects limitations of
> WebCrypto.

I wholeheartedly agree that, regardless of 'main' spec or 'sub-spec', it would be good to nail down a definition, so that we can identify and resolve the issues with Bug 25618 as reasonably quickly as possible, to make sure the language *supports* extensibility. See the NUMS curves discussion (particularly, http://lists.w3.org/Archives/Public/public-webcrypto/2014Jul/0045.html ) to understand more of my concerns there.

(In reply to Ryan Sleevi from comment #47)
> (In reply to Trevor Perrin from comment #46)
> > (In reply to Ryan Sleevi from comment #45)
> > > - Suitable normative reference (TLS is still debating this)
> > > - Suitable key format reference (TLS is still debating this)
> > 
> > Is Dan Bernstein's paper from PKC 2006 not a sufficient reference?  It's
> > available at stable URLs in a couple places, contains a detailed algorithm
> > description, and is widely cited as "the" curve25519 paper:
> > 
> > http://cr.yp.to/ecdh/curve25519-20060209.pdf
> > http://www.iacr.org/cryptodb/archive/2006/PKC/3351/3351.pdf
> > 
> > There are multiple independent implementations.  I've never heard of interop
> > problems.
> 
> Nope! It's not, that's part of the delay.
> 
> For example, how do you represent such a key in a subjectPublicKeyInfo? Is
> it a OID for a NamedCurve (which is the only format that Web Crypto
> supports) on an id-ecPublicKey AlgorithmInfo? Is it something else?
> 
> What about for PKCS#8?

Don't care!

The several Javascript crypto projects I'm advising don't use PKIX, S/MIME, JOSE, or PKCS#8.  If Curve25519 needs number registration for those, then that seems like an issue for those protocols, not a concern for a low-level crypto library.

Are you saying WebCrypto can't support new algorithms unless they're registered with a half-dozen IETF protocols most people don't care about?

I guess I expected a low-level API to just provide Curve25519 keys with ECDH, and Ed25519 keys with sign/verify (since by convention and for performance/security reasons, Curve25519 is mostly used with different encodings for public/private keys in signatures vs ECDH, and Schnorr signatures are used rather than ECDSA).

I could imagine these creating some issues for your API, and those seem like good things to discuss further.  But having to specify PKIX or JWK bindings seems unnecessary and a layering violation.


> Should it work with JWK? If so, who is responsible for the JWA registration,
> and how does that relate with JWA's choice to represent points (see
> https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms - JOSE knows
> that the format won't work with Curve25519 as written)

I think that's for someone who cares about "JWK" to worry about.


> > Whether this makes sense in the core document or a separate one I don't know.
> > 
> > But if there are issues with including Curve25519 in WebCrypto's notion of a
> > "curve", as some comments in this bug imply, it may be worth working this
> > out before the core documents issue, in case this reflects limitations of
> > WebCrypto.
> 
> I wholeheartedly agree that, regardless of 'main' spec or 'sub-spec', it
> would be good to nail down a definition, so that we can identify and resolve
> the issues with Bug 25618 as reasonably quickly as possible, to make sure
> the language *supports* extensibility. See the NUMS curves discussion
> (particularly,
> http://lists.w3.org/Archives/Public/public-webcrypto/2014Jul/0045.html ) to
> understand more of my concerns there.

So what's the way forward?  Should this discussion switch to Bug 25618?  Is anyone working on a more streamlined way to add new algorithms?

Trevor

(In reply to Trevor Perrin from comment #48)
> Don't care!
> 
> The several Javascript crypto projects I'm advising don't use PKIX, S/MIME,
> JOSE, or PKCS#8.  If Curve25519 needs number registration for those, then
> that seems like an issue for those protocols, not a concern for a low-level
> crypto library.

No, it's a concern for our library too, with regards to importKey, exportKey, and wrap/unwrap.

Even if you decide to hand-wave these formats to the ground (which doesn't seem entirely appropriate, since there is active work going on precisely to standardize these), you still have to define what "raw" means, in the specific context of WebCrypto, and ideally in a way that will interoperate with other, non-WebCrypto things.

Of the multiple Curve25519 implementations, very few that I'm aware of try to actually interoperate with eachother, or with any other protocol. Even the native language bindings for things like NaCl attempt to just use the djb-reference implementation, and just wrap that. So it is a bit questionable on the 'interoperability', but it at a minimum requires a formal definition for what format(s) are supported for these operations.

For what it's worth, people do care about JWK, and they do care about SPKI.

> Are you saying WebCrypto can't support new algorithms unless they're
> registered with a half-dozen IETF protocols most people don't care about?

I didn't say anything close to that.

I just mentioned that these are exposed API surfaces of WebCrypto, and, as of yet, no one has proposed on how to deal with them. Your proposal is "Don't deal with them", which is a proposal, and one which should be discussed on it's merits, preferably when reviewing such text.

> 
> I guess I expected a low-level API to just provide Curve25519 keys with
> ECDH, and Ed25519 keys with sign/verify (since by convention and for
> performance/security reasons, Curve25519 is mostly used with different
> encodings for public/private keys in signatures vs ECDH, and Schnorr
> signatures are used rather than ECDSA).

Yes, I can reasonably imagine that, but imagination and specification are two different things.

The fact that Curve25519 does not work with ECDSA, or that the Schnorr signatures are used, are exactly the kind of things that need specification in order for interoperability (and without just aping the djb@ code, even if it is extremely high quality and correct and reasonably licensed for most needs) 

> 
> I could imagine these creating some issues for your API, and those seem like
> good things to discuss further.  But having to specify PKIX or JWK bindings
> seems unnecessary and a layering violation.

I imagine that you missed importKey, exportKey, wrap and unwrap during review.

> > Should it work with JWK? If so, who is responsible for the JWA registration,
> > and how does that relate with JWA's choice to represent points (see
> > https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms - JOSE knows
> > that the format won't work with Curve25519 as written)
> 
> I think that's for someone who cares about "JWK" to worry about.

WebCrypto cares about JWK.

> So what's the way forward?  Should this discussion switch to Bug 25618?  Is
> anyone working on a more streamlined way to add new algorithms?
> 
> Trevor

Concrete steps:
- Make an effort to write an independent specification for Curve25519
- Everywhere you find you cannot (e.g. every time you have to "monkey patch" the spec and say something like "Add this line to this conditional") file a bug against the spec, as that's something that blocks Bug 25618
- At the end of the day, you will have a specification that describes how UAs can/should implement Curve25519 (and presumably Ed25519)
- The WG will discuss as to whether to add this as a chartered work item
- Convince UAs to implement

(In reply to Ryan Sleevi from comment #49)
> (In reply to Trevor Perrin from comment #48)
> > Don't care!
> > 
> > The several Javascript crypto projects I'm advising don't use PKIX, S/MIME,
> > JOSE, or PKCS#8.  If Curve25519 needs number registration for those, then
> > that seems like an issue for those protocols, not a concern for a low-level
> > crypto library.
> 
> No, it's a concern for our library too, with regards to importKey,
> exportKey, and wrap/unwrap.
> 
> Even if you decide to hand-wave these formats to the ground (which doesn't
> seem entirely appropriate, since there is active work going on precisely to
> standardize these), you still have to define what "raw" means, in the
> specific context of WebCrypto, and ideally in a way that will interoperate
> with other, non-WebCrypto things.

The "raw" definitions would be straightforward, as the Curve25519 and Ed25519 papers specify exact encodings for keys and signatures.


> Of the multiple Curve25519 implementations, very few that I'm aware of try
> to actually interoperate with eachother, or with any other protocol.

I've talked to some developers of these libraries who indeed have performed interop tests.  The DJB specs are very clear, and the formats are very simple.  I'd be surprised if any serious implementations of Curve25519 ECDH and Ed25519 signatures failed to interoperate.


> Even
> the native language bindings for things like NaCl attempt to just use the
> djb-reference implementation, and just wrap that. So it is a bit
> questionable on the 'interoperability', but it at a minimum requires a
> formal definition for what format(s) are supported for these operations.

It's true that most people use one of the high-quality open-source implementations that Dan Bernstein or Adam Langley have produced, or implementations derived from these (by Frank Denis, Robert Ransom, floodyberry, CodesInChaos, etc).

That speaks to the quality of these implementations, it doesn't imply interop problems.


> For what it's worth, people do care about JWK, and they do care about SPKI.

Some people do, some people don't.

Personally I'm more interested in TextSecure, Tor, PGP, SSH, OTR and variants, CryptoCat/miniLock, and others.  I don't think WebCrypto should refuse algorithms of interest to large communities just because they aren't used within PKIX or JOSE.


> > Are you saying WebCrypto can't support new algorithms unless they're
> > registered with a half-dozen IETF protocols most people don't care about?
> 
> I didn't say anything close to that.
> 
> I just mentioned that these are exposed API surfaces of WebCrypto, and, as
> of yet, no one has proposed on how to deal with them. Your proposal is
> "Don't deal with them", which is a proposal, and one which should be
> discussed on it's merits, preferably when reviewing such text.

My proposal would be to define the "raw" formats for import/export now, and add other formats ("jwk", "pkcs8", "spki") if/when they become available.


> > I guess I expected a low-level API to just provide Curve25519 keys with
> > ECDH, and Ed25519 keys with sign/verify (since by convention and for
> > performance/security reasons, Curve25519 is mostly used with different
> > encodings for public/private keys in signatures vs ECDH, and Schnorr
> > signatures are used rather than ECDSA).
> 
> Yes, I can reasonably imagine that, but imagination and specification are
> two different things.
> 
> The fact that Curve25519 does not work with ECDSA, or that the Schnorr
> signatures are used, are exactly the kind of things that need specification
> in order for interoperability (and without just aping the djb@ code, even if
> it is extremely high quality and correct and reasonably licensed for most
> needs)

Curve25519 public keys can be encoded in Edwards form (Ed25519), and in that form could be used with ECDSA.  However people using 25519 would expect Schnorr signatures.

"Aping" code for these isn't needed.  Like Curve25519 ECDH, the Ed25519 signature format is well-specified in a published paper:

http://ed25519.cr.yp.to/ed25519-20110926.pdf


> > I could imagine these creating some issues for your API, and those seem like
> > good things to discuss further.  But having to specify PKIX or JWK bindings
> > seems unnecessary and a layering violation.
> 
> I imagine that you missed importKey, exportKey, wrap and unwrap during
> review.

I see them, I just think it's strange for this API to be concerned with outputting keys in various application formats.

Adding or parsing JSON/XML/ASN.1/etc boilerplate can be done in Javascript without special performance or security considerations.  It doesn't seem that important to perform this in the browser.

It's also weird to favor such specific protocols, to the point that not being used in them is an argument against adopting crypto that's widely used elsewhere.


> > So what's the way forward?  Should this discussion switch to Bug 25618?  Is
> > anyone working on a more streamlined way to add new algorithms?
> > 
> > Trevor
> 
> Concrete steps:
> - Make an effort to write an independent specification for Curve25519

OK.  

So if I specified "Curve25519" and "Ed25519" algorithms that only define import/export using the "raw" formats and the DJB-defined standard encodings, this would be considered?

Is there an example template for producing add-on algorithm documents?  Are any spec editors or other people willing to help, as I'm new here?


Trevor

(In reply to Trevor Perrin from comment #50)
> The "raw" definitions would be straightforward, as the Curve25519 and
> Ed25519 papers specify exact encodings for keys and signatures.

Though I don't agree with that, it's something better discussed when reviewing a spec you wrote, rather than on this bug.

> > Of the multiple Curve25519 implementations, very few that I'm aware of try
> > to actually interoperate with eachother, or with any other protocol.
> 
> I've talked to some developers of these libraries who indeed have performed
> interop tests.  The DJB specs are very clear, and the formats are very
> simple.  I'd be surprised if any serious implementations of Curve25519 ECDH
> and Ed25519 signatures failed to interoperate.

Though I don't agree with this either, it's something better discussed when reviewing a spec you wrote, rather than on this bug.

> That speaks to the quality of these implementations, it doesn't imply
> interop problems.

If the only way to interop is to read source, that is an interop problem.
If the only way to interop is to use one of the canonical sources, that too is an interop problem (c.f. WebSQL)

> > For what it's worth, people do care about JWK, and they do care about SPKI.
> 
> Some people do, some people don't.
> 
> Personally I'm more interested in TextSecure, Tor, PGP, SSH, OTR and
> variants, CryptoCat/miniLock, and others.  I don't think WebCrypto should
> refuse algorithms of interest to large communities just because they aren't
> used within PKIX or JOSE.

We're neither accepting nor refusing. I'm simply giving you a set of concerns that you'll likely need to address during discussion.

I don't think I'd be supportive of this without at least JWK support.

> My proposal would be to define the "raw" formats for import/export now, and
> add other formats ("jwk", "pkcs8", "spki") if/when they become available.

"Someone" has to define the JWK spec. Look at ours - we already register several JWAs specifically to support JWK with WebCrypto. It's certainly possible for your spec to do the same.

Whether or not you do is your choice, but it's one that will at least be discussed. I don't think without at least JWK I'd be supportive.


> "Aping" code for these isn't needed.  Like Curve25519 ECDH, the Ed25519
> signature format is well-specified in a published paper:
> 
> http://ed25519.cr.yp.to/ed25519-20110926.pdf

While I appreciate the enthusiasm, it may be worth re-reading that paper. It doesn't (at least as far as I recall and found) specify how to deal with octet strings. That is, the algorithms are defined in terms of integers, but the format conversions are left ambiguous.

> I see them, I just think it's strange for this API to be concerned with
> outputting keys in various application formats.
> 
> Adding or parsing JSON/XML/ASN.1/etc boilerplate can be done in Javascript
> without special performance or security considerations.  It doesn't seem
> that important to perform this in the browser.
> 
> It's also weird to favor such specific protocols, to the point that not
> being used in them is an argument against adopting crypto that's widely used
> elsewhere.

Every modern crypto API supports some form of key input. You can either abstractly reduce it to the same primitives of SPKI (e.g. reducing an RSAPublicKey to n/e params, an RSAPrivateKey to n/e/d/p/q/etc) or you can take the forms in native.

This is a Web API, and using a JSON-like structure for parameters is idiomatic. As it happens, JWK is a JSON-like structure for parameters, and takes the primitives you want.

I would disagree on the assertion of both "without special performance" concerns (which we can show to be false), and, at least by the arguments in favour of wrapKey/unwrapKey and the "extractable" flag, some members of the WG clearly feel that there are security concerns.

Specifically, if you only support "raw", then you cannot "securely" (a term I use based on other members' recorded views) support unwrapping of Curve25519 keys. That is, the 'sender' can control extractability by setting the JWK "ext" attribute prior to wrapping, then wrap the key. The recipient is documented as respecting the "ext" attribute independent of the content script's parameters to unwrapKey.

> > Concrete steps:
> > - Make an effort to write an independent specification for Curve25519
> 
> OK.  
> 
> So if I specified "Curve25519" and "Ed25519" algorithms that only define
> import/export using the "raw" formats and the DJB-defined standard
> encodings, this would be considered?

If you specified them with no encodings, it'd be considered.
If you specified them with the Trevor Perrin Awesome Encodings, it'd be considered.

The point being that, as a WG, we'll "consider" all submissions. But the choice or absence of some features will have an affect on whether or not the WG adopts it as a WG item, and whether or not the WG is able to progress on this.

> Is there an example template for producing add-on algorithm documents?  Are
> any spec editors or other people willing to help, as I'm new here?

No example templates. New territory being charted here. Each "Algorithm" section in the main spec "SHOULD" (e.g. if the main spec's main UA processing algorithms) be an example of what's necessary. In practice, I suspect it's not - least of all because of how the "NamedCurve" enum behaves - and those are bugs that need to be filed against the spec. I don't know all the places, which is why we have the general bug, because we do know it's wrong, but none of the people who have reviewed the spec have taken the time to call out the places they see.

As for formatting, well, it's W3C, use whatever you want. ReSpec.js is pretty hip and popular. It just has to pass the W3C PubRules checks if we were to push it.

(In reply to Ryan Sleevi from comment #51)
> (In reply to Trevor Perrin from comment #50)
> > The "raw" definitions would be straightforward, as the Curve25519 and
> > Ed25519 papers specify exact encodings for keys and signatures.
> 
> Though I don't agree with that, it's something better discussed when
> reviewing a spec you wrote, rather than on this bug.
> 
> > > Of the multiple Curve25519 implementations, very few that I'm aware of try
> > > to actually interoperate with eachother, or with any other protocol.
> > 
> > I've talked to some developers of these libraries who indeed have performed
> > interop tests.  The DJB specs are very clear, and the formats are very
> > simple.  I'd be surprised if any serious implementations of Curve25519 ECDH
> > and Ed25519 signatures failed to interoperate.
> 
> Though I don't agree with this either, it's something better discussed when
> reviewing a spec you wrote, rather than on this bug.
> 
> > That speaks to the quality of these implementations, it doesn't imply
> > interop problems.
> 
> If the only way to interop is to read source, that is an interop problem.
> If the only way to interop is to use one of the canonical sources, that too
> is an interop problem (c.f. WebSQL)

That's not the case - the DJB papers on Curve25519 and Ed25519 specify byte-level detail.

But I appreciate this would be better discussed via a full proposal.


> While I appreciate the enthusiasm, it may be worth re-reading that paper. It
> doesn't (at least as far as I recall and found) specify how to deal with
> octet strings. That is, the algorithms are defined in terms of integers, but
> the format conversions are left ambiguous.

Byte-level encodings for public keys and signatures are on pages 6 and 7:

http://ed25519.cr.yp.to/ed25519-20110926.pdf

They could be more prominent, but they're there (search for "encoding").


> Specifically, if you only support "raw", then you cannot "securely" (a term
> I use based on other members' recorded views) support unwrapping of
> Curve25519 keys. That is, the 'sender' can control extractability by setting
> the JWK "ext" attribute prior to wrapping, then wrap the key. The recipient
> is documented as respecting the "ext" attribute independent of the content
> script's parameters to unwrapKey.

I see.  I didn't realize JWK was the privileged format for wrap / unwrap.


> The point being that, as a WG, we'll "consider" all submissions. But the
> choice or absence of some features will have an affect on whether or not the
> WG adopts it as a WG item, and whether or not the WG is able to progress on
> this.
> 
> > Is there an example template for producing add-on algorithm documents?  Are
> > any spec editors or other people willing to help, as I'm new here?
> 
> No example templates. New territory being charted here.

OK, I'll see what I can do.  Could take a few weeks, if anyone wants to help let me know.


Trevor

(In reply to Trevor Perrin from comment #52)
> OK, I'll see what I can do.  Could take a few weeks, if anyone wants to help
> let me know.

Don't have time to help, but want to sincerely thank you Trevor for doing this! You're awesome! :D

(In reply to Trevor Perrin from comment #52)

> 
> OK, I'll see what I can do.  Could take a few weeks, if anyone wants to help
> let me know.
> 
> 
> Trevor

Trevor,
Thanks for your continuous efforts to help the Web Crypto API to get improved.
The Web Crypto WG is in the process to exit Last Call. As such, we need to solve as many bugs as possible in a short period of time. Could you please confirm that you will actually provide a contribution, and give us a suitable deadline when you will deliver it.
Thanks,
virginie
chair of Web Crypto WG

(In reply to virginie.galindo from comment #54)
> Trevor,
> Thanks for your continuous efforts to help the Web Crypto API to get
> improved.
> The Web Crypto WG is in the process to exit Last Call. As such, we need to
> solve as many bugs as possible in a short period of time. Could you please
> confirm that you will actually provide a contribution, and give us a
> suitable deadline when you will deliver it.

Hi Virginie,

I'll provide an initial draft within 2 weeks, so by August 10.

Trevor

(In reply to Trevor Perrin from comment #55)
> (In reply to virginie.galindo from comment #54)
> > Trevor,
> > Thanks for your continuous efforts to help the Web Crypto API to get
> > improved.
> > The Web Crypto WG is in the process to exit Last Call. As such, we need to
> > solve as many bugs as possible in a short period of time. Could you please
> > confirm that you will actually provide a contribution, and give us a
> > suitable deadline when you will deliver it.
> 
> Hi Virginie,
> 
> I'll provide an initial draft within 2 weeks, so by August 10.
> 
> Trevor


(In reply to Trevor Perrin from comment #55)
> (In reply to virginie.galindo from comment #54)
> > Trevor,
> > Thanks for your continuous efforts to help the Web Crypto API to get
> > improved.
> > The Web Crypto WG is in the process to exit Last Call. As such, we need to
> > solve as many bugs as possible in a short period of time. Could you please
> > confirm that you will actually provide a contribution, and give us a
> > suitable deadline when you will deliver it.
> 
> Hi Virginie,
> 
> I'll provide an initial draft within 2 weeks, so by August 10.
> 
> Trevor

The problem, as BAL pointed on the call, is that we do *not* have resolution on a single curve from TLS or CFRG.  It is unclear when those decisions will be made, although a decision is likely I would say before we exist CR. However, chosing between NUMS and 25519 may be premature optimization at this point. Nonetheless, as BAL noted on the call and was backed up on the Bugzilla, there is a real demand for non-NIST ECC curve support in Web Crypto.

In this regard, Trevor's draft needs to be done regardless, in particular to answer the concerns voiced by Ryan. 

In general, in W3C process it is *more* difficult to add features than to subtract them when going into CR. Thus, the "feature at risk" mechanism.

So, I'd like to add another proposal.  I suggest that we simply add a "feature at risk", using a modification of BAL's edits, for a "TBD non-NIST" curve in the main spec. This TBD curve, if not resolved and supported by CFRG/TLS by the time we exit from CR, is then to be removed from the main spec. If it is later resolved after we have exited CR, then we propose to add these curves using the standard extension mechanism.

Trevor's work on 25519 or BAL's work on NUMS could then go into spec via either of those routes, and we'd effectively make the decision when exiting CR. CR also has the added benefit of helping us see what curves are supported in the test-suite. 

   cheers,
      harry

Hi,

Here's a proposal for an ECDH-CURVE25519 algorithm:

http://htmlpreview.github.io/?https://github.com/trevp/curve25519_webcrypto/blob/master/Curve25519_WebCrypto.html

Since ECDH is simpler than signatures, I wanted to work through this before tackling Ed25519.  But I was thinking of SCHNORR-ED25519 on similar lines.

If people like the naming you could name other algorithms like ECDH-NIST, ECDSA-NIST, ECDH-NUMS, etc.

JWK private keys are supported via the "oct" type, as it's a key "whose value is a single octet sequence".

Public keys are only imported/exported in raw format, not JWK.  The JWK "EC" requires SECG for encoding, and requires X and Y coordinates, so is not suitable for X-coordinate-only ECDH like Curve25519.

FYI
As a follow up on Trevor Perrin contribution, a call for consensus has been made on the Web Crypto WG, to handle that contribution as an extension to the main Web Crypto API, meaning as a separate document, having its own track recommendation. See http://lists.w3.org/Archives/Public/public-webcrypto/2014Aug/0102.html

Virginie

FYI
conf call to discuss with Trevor Perrin on curve25519 draft scheduled on monday 18th of August
See http://lists.w3.org/Archives/Public/public-webcrypto/2014Aug/0124.html

I support Matt Corallo's proposal to have curve25519 included in the NamedCurve dictionary.
This is a very long thread which I've taken care to read.  
If you are here reading this, I would also like to add as an aside, if you have not yet, please read a Telegraph story on Sir Tim Berners-Lee, from Oct. 8, 2014, in which Sir Tim Berners-Lee was quoted (partly shown below):
"People and companies function by having an information boundary, and the information within that boundary defines the group. That’s the way society works. The idea that privacy is dead is hopeless and sad. We have to build systems which allow privacy." 
(from http://www.telegraph.co.uk/technology/internet/11148584/Tim-Berners-Lee-calls-for-new-model-for-privacy-on-the-web.html)
Thank you

(In reply to Colin Gallagher from comment #60)
> I support Matt Corallo's proposal to have curve25519 included in the
> NamedCurve dictionary.
> This is a very long thread which I've taken care to read.  
> If you are here reading this, I would also like to add as an aside, if you
> have not yet, please read a Telegraph story on Sir Tim Berners-Lee, from
> Oct. 8, 2014, in which Sir Tim Berners-Lee was quoted (partly shown below):
> "People and companies function by having an information boundary, and the
> information within that boundary defines the group. That’s the way society
> works. The idea that privacy is dead is hopeless and sad. We have to build
> systems which allow privacy." 
> (from
> http://www.telegraph.co.uk/technology/internet/11148584/Tim-Berners-Lee-
> calls-for-new-model-for-privacy-on-the-web.html)
> Thank you

Colin,
W3C Web Crypto WG is not ignoring curve 25519. We are just waiting IETF CFRG to come with a clear decision that it will be part of their recommended technology for the future. 
In addition, there is a extensibility/errata mechanism the WG is currenlty discussing whihc will allow to integrate such algo. 
virginie
chair of eb crypto WG

Hello,

Since there is apparently a process of waiting for IETF CFRG "to come with a clear decision that it will be part of their recommended technology for the future," in order to proceed on the curve25519 matter, I wish to add that there appear to be unresolved questions about the CFRG itself in terms of NSA affiliation of a co-chair, as shown here:
http://www.ietf.org/mail-archive/web/cfrg/current/msg03554.html
If I am mistaken ~ that is, if the co-chair with NSA affiliations has been removed, then I have no objections to waiting for IETF CFRG. However, if an NSA-affiliated co-chair is still there, then I do have objections to the wait and hope approach.
Thank you

See also comment(s) 59 and 60 at https://www.w3.org/Bugs/Public/show_bug.cgi?id=25618#c59 

Thank you

(In reply to Colin Gallagher from comment #62)

Regarding the CFRG co-chairs, Kevin M. Igoe's retiring and is no longer acting as a co-chair - that matter is resolved. 

CFRG is hoping to have a decision ready for you by December (and as you see, I'm trying to move progress along!).

I would add, however, that I don't think you should necessarily wait for CFRG's answer to the request of the TLS Working Group for recommendations: outside the IETF, many others haven't. (CFRG already achieved consensus that Curve25519 is good, even before the TLS Working Group's request, by the way.)

X25519 (the DH algorithm using the curve Curve25519; djb changed his terminology to make things clearer there) and Ed25519 (specifically EdDSA-twistededwards25519-SHA512) have already achieved very wide public post-Snowden use, as you can indeed see on Wikipedia (Apple, OpenWhisperSystems, SSH) - so no matter what CFRG eventually recommend, not including 25519 in a crypto API like this will definitely raise eyebrows and some people will keep rolling their own, which I'm sure you want to avoid.

If CFRG eventually select something else (there'll probably be a larger curve as well as a ~256-bit one, but I don't know which yet), I think you should add that to NamedCurve as well.

Yes, there are multiple interoperable implementations of Curve25519's core algorithms (four or five on my last count, although not all include the scalarmul for Ed25519 as well?), including at least one in hardware.

Note that Trevor Perrin's draft of Curve 25519 resolves this issue. It will be sent to Working Draft at the same time WebCrypto goes to CR.. Also, we are actively waiting for the CFG recommendation.

https://github.com/trevp/curve25519_webcrypto

(In reply to Harry Halpin from comment #66)
> Note that Trevor Perrin's draft of Curve 25519 resolves this issue. It will
> be sent to Working Draft at the same time WebCrypto goes to CR.. Also, we
> are actively waiting for the CFG recommendation.
> 
> https://github.com/trevp/curve25519_webcrypto

s/sent to Working Draft/proposed to the WG for adoption/

Let's not forget process :)

We have in principle agreed to adopt the draft and did a call with Trevor Perrin to discuss. 


http://lists.w3.org/Archives/Public/public-webcrypto/2014Aug/0102.html

As is in-line with the results of our call for consensus that called for CFRG liaisoning and then putting separate curves in separate documents (as Richard agreed to). 

Thus, we can put it as an "Editor's Draft" in W3C space. However, yes, we can also do a separate call out for consensus on the document as a Working Draft. Will ping Virginie to send out that call for consensus.

We do not, to my knowledge, have a separate NUMS Editor's Draft. Of course, one can be created at any time and the WG can be alerted. 

However, note we are definitely in the resolved with "LATER" category with the production and adoption of the Curve 25519 draft and errata-extensibility mechanism for this long-standing bug.

Does the issue already fixed? any current update? Thanks 

Waynem Ccollough
https://amsterdamdiary.com/

Does the issue already fixed? any current update? Thanks 

Waynem Ccollough
https://amsterdamdiary.com/