[Bug 25839] Curve25519 Named Curve

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

--- Comment #14 from Greg Slepak <hi@okturtles.com> ---
(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)"?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Saturday, 24 May 2014 18:55:16 UTC