[Bug 25839] Curve25519 Named Curve

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

--- Comment #26 from Ryan Sleevi <sleevi@google.com> ---
(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.

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

Received on Thursday, 12 June 2014 20:02:21 UTC