[Bug 25839] Curve25519 Named Curve

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

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

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

Received on Thursday, 12 June 2014 08:39:30 UTC