[Bug 25839] Curve25519 Named Curve

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

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

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

Received on Monday, 4 August 2014 14:18:33 UTC