- 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