- From: Harry Halpin <hhalpin@w3.org>
- Date: Wed, 27 Aug 2014 02:24:44 +0200
- To: public-webcrypto@w3.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/27/2014 02:19 AM, Ryan Sleevi wrote: > On Tue, Aug 26, 2014 at 5:18 PM, Harry Halpin <hhalpin@w3.org> > wrote: > > > > On 08/27/2014 02:10 AM, Ryan Sleevi wrote: >>>> Given that I view all the algorithms as extension specs, and >>>> would love to pull them all out to that, I too support this. >>>> >>>> It's the same one way or another, which has been the whole >>>> point. > > I see the emails passed each other in the dark :) > > >> Well, as per usual, I believe we're talking about different >> things. Please do not consider the above proposal to your >> modified version (having an ECC extension spec proceed to REC >> track simultaneously), which is not what Mark stated (having an >> ECC extension spec). Please clarify. I believe Mark just said "pulling EC out of the specification altogether". That could either be 1) An extension spec for NIST ECC curves 2) An extension spec for *multiple* ECC curves Either is fine with me. cheers, harry > >> The latter half is, naturally, the entire crux of the >> contention. > > > > BAL, would you support that if NUMS does not make it into the main > spec text, that you would be OK with pulling out all ECC curves? > >>>> >>>> >>>> On Tue, Aug 26, 2014 at 5:07 PM, Mark Watson >>>> <watsonm@netflix.com> wrote: >>>> >>>>> I am finding the option of pulling EC out of the >>>>> specification altogether and addressing it in a separate >>>>> document more and more attractive: The first WebCrypto EC >>>>> specification would contain non-NIST curves. We can work at >>>>> an appropriate pace, given the dependencies on other groups >>>>> and we can avoid delaying the rest of our main document. >>>>> >>>>> ...Mark >>>>> >>>>> >>>>> On Tue, Aug 26, 2014 at 5:03 PM, Ryan Sleevi >>>>> <sleevi@google.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Aug 26, 2014 at 4:57 PM, Harry Halpin >>>>>> <hhalpin@w3.org> wrote: >>>>>> >>>> >>>> >>>> On 08/26/2014 08:39 PM, Ryan Sleevi wrote: >>>>>>>>> On Tue, Aug 26, 2014 at 4:34 AM, Harry Halpin >>>>>>>>> <hhalpin@w3.org> wrote: >>>>>>>>> >>>>>>>>> My opinion is the same as Richard insofar as"We >>>>>>>>> should agree on the principle that we will support >>>>>>>>> the next generation curves that CFRG and TLS agree >>>>>>>>> on, and work to support that once it's decided." >>>>>>>>> But we need to operationalize what we mean by >>>>>>>>> "support". >>>>>>>>> >>>>>>>>> The choices are having that curve in the >>>>>>>>> *extension specs* versus *main spec*. Given that >>>>>>>>> all major browser vendors I know of will implement >>>>>>>>> the recommended set of curves from CFRG to TLS and >>>>>>>>> so exposing those to WebCrypto makes sense - and >>>>>>>>> given the liaison relationship between the IETF and >>>>>>>>> W3C and our commitment to harmonize as much as >>>>>>>>> possible our specs - it seems that that those >>>>>>>>> recommended curves should be in the main spec >>>>>>>>> text. >>>>>>>>> >>>>>>>>> >>>>>>>>>> I strongly disagree with this, as it ignores >>>>>>>>>> quite a bit about how >>>> both >>>>>>>>>> browsers and standards work. >>>>>>>>> >>>>>>>>>> Consider that TLS 1.2 was not implemented for >>>>>>>>>> years after it was standardized. Consider that >>>>>>>>>> the CFRG recommendation will be for TLS 1.3, >>>>>>>>>> which is >>>> growing >>>>>>>>>> in considerable complexity. >>>>>>>>> >>>>>>>>>> Harry, just because a spec (which itself will >>>>>>>>>> have it's own timeline >>>> for >>>>>>>>>> review and discussion, and may change at any >>>>>>>>>> point) adopts something >>>> is not >>>>>>>>>> an argument, at all, for an entirely unrelated >>>>>>>>>> spec to do so. >>>>>>>>> >>>>>>>>> >>>>>>>>> Given that extensibility is still a bit blurry, >>>>>>>>> it's hard to claim we have a good solution for >>>>>>>>> extension specs quite yet. However, I also agree we >>>>>>>>> can't wait around forever for CFRG. >>>>>>>>> >>>>>>>>> >>>>>>>>>> Which is precisely what extension specs are for. >>>>>>>>>> We didn't sit on CSS1 while waiting for VRML or >>>>>>>>>> WebGL to come along. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> This in mind, we can move forward by either: >>>>>>>>> >>>>>>>>> 1) Have a "placeholder" text for it as a "Feature >>>>>>>>> at Risk". The NUMS text could be that placeholder, >>>>>>>>> with a note saying that this may be removed/changed >>>>>>>>> if TLS/CFRG do not recommend NUMS. >>>>>>>>> >>>>>>>>> >>>>>>>>>> This is unacceptable. Placeholders in specs, >>>>>>>>>> particularly ones that >>>> favour >>>>>>>>>> any particular solution during ACTIVE DISCUSSION, >>>>>>>>>> are simply grossly inappropriate, especially for >>>>>>>>>> a spec at the maturity of Web Crypto, compared to >>>>>>>>>> the maturity of the discussions going on. >>>>>>>>> >>>>>>>>>> So that it's clear that it's not NUMS specific, >>>>>>>>>> the objection is to >>>> ADDING >>>>>>>>>> any new features that are "FEATURES AT RISK". >>>>>>>>>> Anything, including >>>> anything >>>>>>>>>> in the spec today, that we believe is still a >>>>>>>>>> "feature at risk" is something we should be >>>>>>>>>> actively working towards moving to an >>>> extension spec. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> and/or >>>>>>>>> >>>>>>>>> 2) Go back to "Last Call" and add the recommended >>>>>>>>> non-NIST curve in later in the main spec text. >>>>>>>>> >>>>>>>>> >>>>>>>>>> Or 3), what's been said all along, which is "Add >>>>>>>>>> new curves as they >>>> become >>>>>>>>>> available, both in specification and >>>>>>>>>> implementation, and UAs are >>>> confident >>>>>>>>>> in the maturity such that they're willing to >>>>>>>>>> expose and support as an indefinite part of the >>>>>>>>>> Web platform" >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I see no harm in either of these proposals and >>>>>>>>> think either would satisfy the problem. It's not as >>>>>>>>> simple as adding in NUMS or not. What we need is a >>>>>>>>> commitment to support whatever TLS/CFRG recommend. >>>>>>>>> >>>>>>>>> If TLS/CFRG do *not* recommend a set of non-NIST >>>>>>>>> curves by the necessary timeline for WebCrypto >>>>>>>>> (i.e. getting out of CR by end of the year), in the >>>>>>>>> first case we simply drop the "Feature at Risk" and >>>>>>>>> in the second case we simply do not go back to >>>>>>>>> "Last Call" but progress to Rec as normal. >>>>>>>>> >>>>>>>>> >>>>>>>>>> Frankly, a spec intentionally placing something >>>>>>>>>> that is >>>> unimplementable AND >>>>>>>>>> unspecifiable ("a placeholder") is unacceptable. >>>>>>>>>> A spec intentionally placing something that is >>>>>>>>>> known as "something >>>> we're >>>>>>>>>> probably going to rip out" - whether it be >>>>>>>>>> Curve25519 or NUMS - is unacceptable. >>>> >>>> However, it appears that simply ignoring the issue of >>>> non-NIST curves in the main text spec is also unacceptable to >>>> Microsoft and a good deal of real-world developers. So let's >>>> find a reasonable position we can all agree on that shows >>>> that we have a firm commitment to non-NIST curves but allows >>>> us to continue progress. >>>> >>>> My proposal is that the WebCrypto WG make a firm commit to >>>> honor the desire for a non-NIST curve in the main spec text >>>> *regardless* of our internal timing for transition to Rec. >>>> >>>>>>> >>>>>>> You're asking the WG to make a firm commitment to >>>>>>> something that is neither standardized nor defined. >>>>>>> >>>>>>> That cannot be done, and I hope you realize the sort >>>>>>> of process violation it would be encouraging. >>>>>>> >>>>>>> >>>> >>>> In the case that these are *not* ready by the time we get to >>>> transition out of CR into PR, then we simply update the main >>>> spec to have a non-NIST curve *after* Rec. If somehow they do >>>> resolve before we leave CR, then we just go back to Last >>>> Call. Having a "feature at risk" in the spec here makes sense >>>> so that developers know we are watching the space and are >>>> ready to act ASAP, but it is not strictly necessary. >>>> >>>>>>> >>>>>>> Harry, you know an extension spec is equally viable >>>>>>> for acting ASAP. The WebApps WG is perfectly capable >>>>>>> of demonstrating this if you need historic examples of >>>>>>> new features, such as Service Workers, that can be >>>>>>> explored rapidly. >>>>>>> >>>>>>> >>>> >>>> If the spec is past PR and we can't go back to Last Call, >>>> then we'd just make it WebCrypto version 1.1 and put the >>>> CFRG/TLS non-NIST curve in the main spec text then. >>>> >>>> Of course, if CFRG/TLS discussion - or if the CFRG/TLS >>>> recommendations are such that that browser vendors never >>>> implement - never resolves then we never update the spec. >>>> >>>> I suggest then we inform CFRG and TLS about our formal >>>> dependency on their decision with the above plan of action. I >>>> believe this would resolve the open issue for support >>>> non-NIST curves, although I am not sure if it would resolve >>>> BAL's objections. >>>> >>>>>>> >>>>>>> Let's be clear: I object to this formal dependency. I >>>>>>> think you will be speaking for yourself, and not the >>>>>>> consensus of this WG, precisely because we lack >>>>>>> consensus. >>>>>>> >>>>>>> >>>> >>>> In lieu of this, an extension spec for Curve 25519 need to >>>> go forward as well along with double-checking extensibility. >>>> Regarding how this fits in with BAL's objection to the CfC, >>>> IMHO a formal vote should be taken on the NUMS proposal and >>>> more discussion on the point re the algorithm parameters for >>>> curves, where again we have a Google and Microsoft >>>> disagreement. >>>> >>>> cheers, harry >>>> >>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I'm happy to check in with TLS/CFRG on the timeline >>>>>>>>> and tell them we are considering an official >>>>>>>>> dependency with them. >>>>>>>>> >>>>>>>>> Note in the long-run having the spec being >>>>>>>>> extensible is exceedingly important, as regardless >>>>>>>>> of the non-NIST curves recommended by CFRG, various >>>>>>>>> governments and other folks will want their own >>>>>>>>> crypto algorithms. In this regard, the only other >>>>>>>>> issue holding us from going out of CR is likely the >>>>>>>>> lack of clarity over extension specs. While the >>>>>>>>> spec does note that "This algorithm must be >>>>>>>>> extensible, so as to allow new cryptographic >>>>>>>>> algorithms to be added" there is little guidance >>>>>>>>> after that. >>>>>>>>> >>>>>>>>> cheers, harry >>>>>>>>> >>>>>>>>> >>>>>>>>> On 08/25/2014 05:32 PM, GALINDO Virginie wrote: >>>>>>>>>>>> Hi all, This is a kind reminder that this >>>>>>>>>>>> thread is still live until tomorrow. If you >>>>>>>>>>>> have some opinion to give, it is now. There >>>>>>>>>>>> was already an objection to that resolution >>>>>>>>>>>> [1], but this is not a reason for not >>>>>>>>>>>> answering to it. Any feedback will help the >>>>>>>>>>>> chair to evaluate >>>>>>>>>>>> endorsement/rejection/alternative to that >>>>>>>>>>>> resolution. Regards, Virginie >>>>>>>>>>>> >>>>>>>>>>>> [1] >>>>>>>>>>>> >>>> http://lists.w3.org/Archives/Public/public-webcrypto/2014Aug/0107.html >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>> > >>>> From: GALINDO Virginie [mailto:Virginie.Galindo@gemalto.com] Sent: >>>>>>>>>>>> mardi 12 août 2014 15:22 To: >>>>>>>>>>>> public-webcrypto@w3.org Cc: >>>>>>>>>>>> webcrypto@trevp.net; hhalpin@w3.org; Wendy >>>>>>>>>>>> Seltzer Subject: [W3C Web Crypto WG] CfC : >>>>>>>>>>>> Call for Consensus on the integration of >>>>>>>>>>>> curve25519 in WG deliverables (please vote >>>>>>>>>>>> until the 26th of August) >>>>>>>>>>>> >>>>>>>>>>>> Dear all, >>>>>>>>>>>> >>>>>>>>>>>> I would like to call for consensus on the way >>>>>>>>>>>> we will move forward with the contribution >>>>>>>>>>>> provided by Trevor Perrin describing >>>>>>>>>>>> Curve25519 operation [1]. We discussed >>>>>>>>>>>> several options and I would like to submit >>>>>>>>>>>> the following resolution to your vote. >>>>>>>>>>>> >>>>>>>>>>>> Proposed resolution : the WG agrees on the >>>>>>>>>>>> principle that Curve25519 will be added to >>>>>>>>>>>> Web Crypto WG deliverables as an extension to >>>>>>>>>>>> the Web Crypto API specification. An >>>>>>>>>>>> extension being here a separate specification >>>>>>>>>>>> having its own Recommendation Track. >>>>>>>>>>>> >>>>>>>>>>>> Deadline : votes have to be expressed >>>>>>>>>>>> expected until 26th of August 23:59 UTC >>>>>>>>>>>> Guideline for voting : reply to all to this >>>>>>>>>>>> mail, indicating, +1 if you agree with the >>>>>>>>>>>> resolution, -1 means if you object, 0 if you >>>>>>>>>>>> can live with it. While silence means >>>>>>>>>>>> implicit endorsement of the resolution, >>>>>>>>>>>> explicit expression of vote is encouraged, to >>>>>>>>>>>> help the chair measuring the enthusiasm of >>>>>>>>>>>> the WG participants. >>>>>>>>>>>> >>>>>>>>>>>> Note the following additional information : >>>>>>>>>>>> >>>>>>>>>>>> - This extension will be used as a >>>>>>>>>>>> beta test for the extensibility mechanism >>>>>>>>>>>> that we need to address as raised in bug >>>>>>>>>>>> 25618 >>>>>>>>>>>> >>>>>>>>>>>> - The proposed editor is Trevor, as >>>>>>>>>>>> long as Trevor agrees to maintain the >>>>>>>>>>>> document >>>>>>>>>>>> >>>>>>>>>>>> - This resolution does not imply >>>>>>>>>>>> that the draft submitted by Trevor is >>>>>>>>>>>> endorsed in its current state, as the WG did >>>>>>>>>>>> not have a chance to discuss the content. The >>>>>>>>>>>> discussion about that content can be >>>>>>>>>>>> conducted over the mailing list, or during a >>>>>>>>>>>> dedicated call, where we will invite Trevor. >>>>>>>>>>>> >>>>>>>>>>>> Have a great week ! Virginie Chair of the >>>>>>>>>>>> Web Crypto WG >>>>>>>>>>>> >>>>>>>>>>>> [1] >>>>>>>>>>>> >>>> http://lists.w3.org/Archives/Public/public-webcrypto/2014Aug/0064.html >>>>>>>>>>>> >>>>>>>>>>>> >>>> > >>>> ________________________________ This message and any attachments >>>>>>>>>>>> are intended solely for the addressees and >>>>>>>>>>>> may contain confidential information. Any >>>>>>>>>>>> unauthorized use or disclosure, either whole >>>>>>>>>>>> or partial, is prohibited. E-mails are >>>>>>>>>>>> susceptible to alteration. Our company shall >>>>>>>>>>>> not be liable for the message if altered, >>>>>>>>>>>> changed or falsified. If you are not the >>>>>>>>>>>> intended recipient of this message, please >>>>>>>>>>>> delete it and notify the sender. Although all >>>>>>>>>>>> reasonable efforts have been made to keep >>>>>>>>>>>> this transmission free from viruses, the >>>>>>>>>>>> sender will not be liable for damages caused >>>>>>>>>>>> by a transmitted virus. >>>>>>>>>>>> ________________________________ This message >>>>>>>>>>>> and any attachments are intended solely for >>>>>>>>>>>> the addressees and may contain confidential >>>>>>>>>>>> information. Any unauthorized use or >>>>>>>>>>>> disclosure, either whole or partial, is >>>>>>>>>>>> prohibited. E-mails are susceptible to >>>>>>>>>>>> alteration. Our company shall not be liable >>>>>>>>>>>> for the message if altered, changed or >>>>>>>>>>>> falsified. If you are not the intended >>>>>>>>>>>> recipient of this message, please delete it >>>>>>>>>>>> and notify the sender. Although all >>>>>>>>>>>> reasonable efforts have been made to keep >>>>>>>>>>>> this transmission free from viruses, the >>>>>>>>>>>> sender will not be liable for damages caused >>>>>>>>>>>> by a transmitted virus. >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >> > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJT/SVMAAoJEPgwUoSfMzqc6tUQAIoEEiU/5H1osYsuSkYcQOHX Uw5Onb7FeWvWuS1vGX3wYJEoCI+JqejXydx+2eS/q/dCLcg2DV4IsmXbxqlTwaJr scernz7iaRfGkjZ3xTGYt3Ob3i9HQoyZCykxzeSQehELOpCwYIOpnMbqSVHGxrEa OCFOpxeMsaUS8+SnIRggnlhyY47mGfMnL6EktneKCvqNcj5tvoQeDfZ5WJRcjWp/ qfMddwvDTYttQc0CwojRv8bpKKaxjgnSseHVZ0L6hy4L0XKytrf2mCeZL6fiBD3k WdD02P0WXZW/5MfxVrLTEBHdvOVlaU4c/GR/ASyged5YNwrvlFY8ILfgvKg2cSmA zwTjy8pVin0nOIZ6P4jH6t14/MYQEli/60ASnV11yj7CyHwz1W+rNChfGnQcmBzr WTxAZC+ZMV2BHz7FFYfebzAEAlgqwwgMfY/RP/bpQfBwcOCim1sqjzSRtpJ34fP+ fttp9rOB8V9mzODU+N7cwk9YQAdW4kvY8lv239d/hSwbQ4viH6Dce+lpQe1tmGJv uT0YS7Sp75ohulexTczqXac/Wv/DNOfykhrSpD9TkL2bsF3b5VOX6J+i8QGeOe1X svRZSMbN6D26djPi88HHOS0kZNtiCtLoNYAznXOekb9bP6Lss1tSU05jfk8ksftp yWVXIQJhOWHETb+ucNaK =oW1O -----END PGP SIGNATURE-----
Received on Wednesday, 27 August 2014 00:24:52 UTC