RE: [W3C Web Crypto WG] about extensions to Web Crypto specification

Mike,

That's great. But that doesn't change what I wrote in reply - you cannot
suggest that the inclusion is not holding up the spec.

It has, and Microsoft, through its various representatives, have blocked
every attempt at resolution short of what we (Google) view as an unwise,
unworkable, and highly inappropriate plan (including either a placeholder
promising support for something TBD, or including the Microsoft proposal on
the assumption it will be the winner)

Indepdent of solution, this issue HAs and CONTINUES to prevent progress -
and the most sensible and standard approach other than indefinitely
postponing the spec, one which has worked quite well for a number of other
WGs, and which has worked for this very WG, is to remove the contentious
aspects into a separate update until the fundamental issues can be
resolved, while letting the main spec activity progress.

Your objection to that plan, jn addition to your objections to all other
proposals but yours, cannot be seen as anything but continuing to postpone
and block progress.
On Aug 28, 2014 9:41 AM, "Mike Jones" <Michael.Jones@microsoft.com> wrote:

>  As I’ve already written, I **did** speak to Brian yesterday and he’s
> also against removing the NIST EC support.  I know of no one at Microsoft
> who would support removing it, as doing so would needlessly make the spec
> less useful.
>
>
>
> *From:* Ryan Sleevi [mailto:sleevi@google.com]
> *Sent:* Thursday, August 28, 2014 9:37 AM
> *To:* Mike Jones
> *Cc:* GALINDO Virginie; Mark Watson; public-webcrypto@w3.org; Harry Halpin
> *Subject:* RE: [W3C Web Crypto WG] about extensions to Web Crypto
> specification
>
>
>
>
> On Aug 28, 2014 9:33 AM, "Mike Jones" <Michael.Jones@microsoft.com> wrote:
> >
> > I strongly disagree.  There’s no reason to pull our existing EC support,
> because it’s already well-defined and useful.  Keeping it needn’t hold up
> approval of the spec in any way (which I believe is what Mark is worried
> about).
> >
>
> Mike,
>
> It absolutely has and does continue to hold up the spec, as demonstrated
> by your colleagues objections over publishing anything without something
> either unspecified (a placeholder) or inappropriate (NUMS).
>
> Again, I strongly encourage you and your colleagues to work together to
> jointly figure out your position, because this WG is continuining to
> receive different messages that make it unclear what represents personal
> opinion and what represents the opinion of Microsoft as a member.
>
> >
> >
> > As we decide to add new algorithms, we can use extension points to do
> so.  We need to get those right regardless of what algorithms we include
> now.
> >
> >
> >
> > All of that is separate from a decision on whether we want to *also* add
> additional algorithms before approval (which is what I hear Mark primarily
> speaking against).  That’s a point that people of good intent have shown
> disagreement about, and probably should be the actual focus of discussion
> and possibly a consensus call.
> >
> >
> >
> >                                                             -- Mike
> >
> >
> >
> > From: Mark Watson [mailto:watsonm@netflix.com]
> > Sent: Thursday, August 28, 2014 9:22 AM
> > To: Harry Halpin
> > Cc: Ryan Sleevi; GALINDO Virginie; public-webcrypto@w3.org
> >
> > Subject: Re: [W3C Web Crypto WG] about extensions to Web Crypto
> specification
> >
> >
> >>
> >>
> >> >>
> >> >
> >>
> >> > I think we need a clear proposal for how to deal with our existing
> >> > (three) NIST curves, the NUMS curves, and a way that is consistent
> >> > with curves we've had others ask for (the SECG koblitz curves, as
> >> > used by Bitcoin) or related (such as Brainpool).
> >>
> >> +1
> >>
> >> >
> >> > Of course, it seems that the zeitgeist of at least Harry and Brian,
> >> > and perhaps I'm misreading, is that we MUST NOT add these curves
> >> > unless/until the CFRG blesses them, even though they are defined
> >> > curves in real use and real applications.
> >>
> >> No, we should support generically curves in general. The issue that
> >> Brian brought up, and I support, is not MUST NOT add these curves.
> >> It's that *if* CFRG does recommend non-NIST curves, we MUST add them
> >> eventually.
> >>
> >> The spec should be as generic as possible to allow extensions of
> >> different curve types.
> >
> >
> >
> > ​The spec is *already* much more generic than this as it *already*
> allows addition of arbitrary new algorithms, not just new curve types.
> >
> >
> >
> > IIUC, Ryan suggests that he would prefer generic EC and ECDH algorithms
> to which new curves could be added, provided they are sufficiently similar
> in the way they are defined. I see this as a "nice-to-have", but not
> necessary. We could have separate algorithms for similar (e.g. "NIST-like")
> curves. There would be a lot of duplicate text, but we have not shied away
> from duplicate text where a generic solution would suffice anywhere else.
> To specifically answer Ryan's question, yes,
> >
> > this impl
> >
> > ​ies that​
> >
> > we
> >
> > ​would ​
> >
> > have EC-NIST, EC-SECG, EC-NUMS, and variants of each for ECDSA & ECDH,
> even though they all fit within the same encoding space (in terms of SPKI,
> PKCS#8, and JOSE) and the same operational space (in terms of referenced
> specifications?)
> >
> > ​.
> >
> >
> >
> > I don't see this as ideal, but it's a possibility. I just want to be
> clear that we are NOT in a position where the existing specification cannot
> be extended for new curves - it can.​
> >
> >
> >
> > However, as suggested earlier in the week, the desire for extensibility
> of the existing EC / ECDH algorithms, the desire to include non-NIST
> curves, the desire to wait for CFRG, the fact that some curves are defined
> in a very different way from our existing ones and the desire for the
> specification to progress (all positions held in different combinations by
> different people) together point very strongly to pulling our EC and ECDH
> for the moment. That will not delay approval of EC and ECDH, given all of
> the above. Anything else WILL delay the main specification.
> >
> >
> >
> > ...Mark
> >
> > ​
> >
> >
>