[Bug 25839] Curve25519 Named Curve

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

--- Comment #34 from Harry Halpin <hhalpin@w3.org> ---
(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.

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

Received on Thursday, 19 June 2014 15:19:40 UTC