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

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.


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:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>>
>>>
>>> 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/R78AAoJEPgwUoSfMzqcossP/1cqJOQikGlWirV0lgoJSp+b
>>> eJV1/1o8CYGjh8w31COgnOmtONUh3uoHQPZQJp8RzwWik1RWjqB7g1ZecKVTX0NX
>>> 1cdsEmvNwboxCz3TYRU/eXLkGWzXlUT6Mtx8EufwAvk6UAvSGai9ISZUgoKwGFsI
>>> HLAS3qIC/mUqhOHc86+LNaFFgiSH8kKvECOw6zf99QaE4NEuC8ankjNId2KpYcqy
>>> /k4mKbAkpIw2naMzlXsQUJnV+nBwZ37ZXN5l1RNTL8tJkEFmspvoTbA3cHveRtLO
>>> wck09qzpycFsgJrchVuH28oyy8+Zca8Bm2vLrWa0Lr/tbD5TQEZOxw44cSp4OJ7c
>>> ClX7SLncoWy1B/g+ynHEPnMQr6MIVnUG4Sh6AAGlEWD3VhrMD9tj8ItdSMJqfPgK
>>> QykBFEhYXz60h5C3CMQWBIe54qV9ulKqZ4ETHx4k6rWNXXzAdyj8SURLJPiz/+rX
>>> MxbKNpuhtXmoJY7aE9QrxSWPCkJzT81zjxPQ0mLjEyVzYdh+TDjMC9t78BtxIDvn
>>> UQvCDsANcQw8fKekAkd/TwbvpuVvwh7r84UfQ9mpevzKFXBfhozDdb8kATH5QjcF
>>> Nol10nR+aBYqJwrpdGmkt8eJ2YWIlmNnBWV2fqBbuULKFmBkKUv0xkgRpSr8sqvb
>>> BN420K4WX+pAwc0bXIW0
>>> =ugxI
>>> -----END PGP SIGNATURE-----
>>>
>>
>>
>