Re: [W3C Web Crypto WG] CfC : Call for Consensus on the integration of curve25519 in WG deliverables (please vote until the 26th of August)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



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 :)

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/SO8AAoJEPgwUoSfMzqcFLsQAI8uL51JXL5yCUVPew4vzk1e
+2HOOtEYs61Gy8Q9s7IlFzsGmLoEI2t4epR09ENdq/C+d5I/D6z4cNHBebTIov6j
QaVnoBTJBr2fEghAAeoDQppC8q+ZTYkcHDqHESo7/aDhEEweKH1k5lVWpyNLFDtt
l2jjtjdNgO3tycC5HB969mLFNlispgqPBExy6XWbINObOrRVTrYZCSF7L8yfGwMC
jHhBwtCoSnk0CG95H7xflEcy98A++jLddfMxKr2PKYYNp/L/WV8NST8DuLEx1VSp
m2e+7lBEhDUiLf1ny4DEAihPp0bk8v98ZIBiDtsXUC0b5FaTGpUaPKGZEo0eVLKO
Ng3rJiWGYdIgbs3aQUBW1vbfX6+LIf4gLrCycbr9bR3TwZ1FJCm9JG2Kb0dy/2Yy
16o0sUWg7SYsh1I2w5MO//8acIdpuMSP2NOYBI+xZmytmd5Dncg747VvWMkSBeZf
vhmehpaSHawQPuPUCVcngH3Rw6dfcCgSjFY+jqcYMJ13o8bldm5HfuXW/gSovSAu
7s5RBFrupyFp4q+zo6lZ+HKekruJPxDh1FwGZNjLKnQpki4BvkwvEvyAtBUPMDX2
nrte0lX/lUFZbO2K0mnfeuyT+PMNZ37FE248C9PCzSnOe70+ETt9NNCRO3DRVCf4
9JSDUfsiLeIaQtIKfTHL
=I4PQ
-----END PGP SIGNATURE-----

Received on Wednesday, 27 August 2014 00:18:14 UTC