- From: <bugzilla@jessica.w3.org>
- Date: Mon, 04 Aug 2014 14:18:30 +0000
- To: public-webcrypto@w3.org
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