Re: [W3C Web Crypto WG] minutes of our call today

Hash: SHA1

Here's the minutes in text as draft as well!

     * [3]Topics
         1. [4]W3C Process and the Director's consideration of the
            transition to Candidate Recommendation
         2. [5]Reminders about W3C process
         3. [6]Addition of curves (NUMS and 25519) in Bug 25839
         4. [7]Addition of curves (bug #25839)
     * [8]Summary of Action Items

   <trackbot> Date: 11 August 2014

   <wseltzer> BAL: Can we invite the submitter of the 25519 curve?

   <wseltzer> Virginie: As chair I'd like to invite Trevor

   i can if necessary

   <scribe> scribenick: kodonog

   <scribe> scribe: kodonog

W3C Process and the Director's consideration of the transition to
Candidate Recommendation

   Ryan Sleevi unable to make the call, Virginie will send an
   extract of his email to mailing list

   <wseltzer> [9]




   <harry> Director = TimBL

Reminders about W3C process

   <harry> but also acting COO and CEO act in his place sometimes,
   i.e. Ralph Swick and Jeff Jaffe

   Wendy need to assure W3C management that all the objections
   raised during Last Call have been addressed.

   Wendy: Need to have in our archive, minutes, and bugzilla the
   discussions related to questions, sufficient to satisfy the

   <rbarnes> this is far from the most brutal LC process i've seen

   Wendy: Not possible to reach perfection, but hopefully a
   specification that will result in interoperable implementations
   to satisfy most

   virginie: Based on the amount of feedback during LC and our
   efforts to address that feedback, are you (Harry and Wendy)
   comfortable that we have sufficient data to satisfy.

   <wseltzer> [not Jeff Jaffe but Philippe le Hegaret acting as
   Director's desginee]

   harry: What is less clear, is if the resolution is in order
   based on some of the discussion on some of the bugs.

   virginie: Do you see any bugs that have not been properly

   harry: we need to wait until all the bugs are closed to
   properly assess.

   <harry> So obviously there's been some strong disagreement, and
   the Director will look more closely at those, in particular
   one's where formal objections have been filed.

Addition of curves (NUMS and 25519) in Bug 25839


   <harry> I believe there is one Member Formal objection that is
   in principle resolved, and a non-member objection which is not
   clearly resolved.

Addition of curves (bug #25839)

   virginie: Three options detailed in email earlier today. 1) add
   NUMS as an extension; 2) defer extension work; and 3) start
   work on a new extension (have editor)



   virginie: Call of decision over email in the next two weeks

   markw: option 1 is not clear, do you mean writing a new
   specification as a separate document?

   virginie: yes, a separate document

   <wseltzer> acl ba;

   <wseltzer> acl bal

   <harry> Zakim who's making noise?

   bal: would like to add an option 2.5.
   ... given the political situation in the IETF and the CFRG and
   the Internet at large, the W3C should not publish a spec with
   only NIST curves at this time

   <harry> +1

   bal: if we are going to publish at this time, we need something
   besides NIST curves.

   <harry> The debate is CFRG is quite vigorous

   bal: what those curves are exactly is going to be driven by the
   IETF CFRG process

   <harry> I think Trevor plans to add Ed25519

   bal: move the spec forward with the NUMS curves as a
   placeholder for whatever the IETF process results in
   ... if that doesn't get implemented, it can be addressed later
   in the steps towards Recommendation
   ... put everything in extensions not appropriate at this time

   virginie: so, you are proposing to add the additional
   algorithms to the main spec now

   <rbarnes> but if W3C does a separate process, we get to have 2x
   the politics!

   <virginie> other option is : integration of NUMS Non-NIST
   curves in the main spec as a feature at risk and remove it at
   Candidate Recommendation, if it happens that no interoperable
   implementation is demonstrated and aligned with IETF/CFRG

   bal: we should not shovel this off to a parellel extensions
   spec when the NIST curves are in the main spec

   selfissued: arguing from the point of testing our extensibility
   models, we need to have the extensions that didn't make the
   deadline test the extension process
   ... 25519 gives us the opportunity to test our mechanism

   <markw> +1 to what Mike says about needing an extension spec to
   prove out our extensibility points - and needing to do the
   editing to add the extension points

   rbarnes: partially agree with Brian, we do need a path to get
   away from NIST curves,
   ... I am less concerned that this needs to occur in the base
   ... keep the main spec focused on what we have a lot of
   experience with, but show working group committment to address
   not-NIST curves

   harry: we could add to main spec now and delete at a later
   stage on the path of publication if there isn't IETF CFRG
   ... agree with Brian that we need something in the main spec,
   agree with Mike that we need to test the extension mechanism
   ... Ryan is clearly very unhappy with the NUMS curves and
   doesn't not support their addition

   <harry> In generally, historically W3C wants to co-operate with
   IETF and CFRG in this matter.

   bal: what is the timeline for going to CR?

   <harry> We should exit Last Call to CR at end of August (unless
   we keep getting stucks on bugs)

   harry: target 3 months but may take longer, at earliest we will
   exit CR at the end of November

   <virginie> note we still have few bugs open


   <harry> We should exit CR at earliest end of Nov.

   <harry> Assuming test suite goes well.

   bal: if CFRG can't get a recommendation out by November there
   probably won't be one soon
   ... as for implementations, we plan to put them in our Java
   ... it won't be implementation that is the problem, it will be
   consensus of the cryptographic community

   rbarnes: we can write an implementable spec with this feature
   at risk approach, the real problem is a testable spec
   ... because of this I would prefer to stick with more mature
   curves in the base spec

   bal: another way to look at this is to take elliptic curves out
   of the base spec
   ... and create an elliptic curve spec
   ... i offer this for completeness, but i don't think it is the
   right way to go

   rbarnes: there is a baby in that bathwater

   virginie: ok, lets forget that option

   selfissued: don't drop the NIST curves because they are in use
   in embedded environments

   <rbarnes> no, harry, it is :)

   harry: if we are going to be fair, Brian's option makes some

   <virginie> but no one is really supporting it...

   <harry> bal, feel free to type it in IRC

   <harry> I would like to see all options voted for.

   virginie: we are going to provide something in the end

   <harry> Rather than you just choosing one virginie.

   <harry> In fact, that is the process we should do for each
   remaining issue.

   <virginie> Option 1 : integration of NUMS curve as an extension
   to the Web Crypto API specification, based on what was proposed
   by Brian LaMacchia (potentially removing NIST curves)

   <rbarnes> where extension == separate doc

   PROPOSED: Option 1 from the email.

   <virginie> Option 1 : integration of NUMS curve as an extension
   to the Web Crypto API specification, based on what was proposed
   by Brian LaMacchia (potentially removing NIST curve is a
   separate specs) where extension

   <harry> Can you clarify the removing NIST curves?

   <wseltzer> Option 1: addition of NUMS curve as an extension to
   the Web Crypto API specification, based on what was proposed by
   Brian LaMacchia

   virginie: Option 1: (see Wendy's text)

   <virginie> Option 1 : addition of NUMS curve as an extension to
   the Web Crypto API specification, based on what was proposed by
   Brian LaMacchia where extension is a separate document

   <rbarnes> +1

   <wseltzer> [+1 agree, -1 object, 0 can live with]

   <selfissued> 0


   <bal> -1

   <markw> +1 (possibly with note in main spec that this work is

   <harry> -1

   <nvdbleek> +1

   <virginie> +1

   <rbarnes> +1 (obo rsleevi)

   <virginie> as a comment ryan would prefer separate document

   PROPOSED: Option 3 from mailing list: put NUMS in main
   specification with Feature at Risk notation

   <virginie> Option 3 : integration of NUMS Non-NIST curves in
   the main spec as a feature at risk and remove it at Candidate
   Recommendation, if it happens that no interoperable
   implementation is demonstrated, aligning with IETF / CFRG

   virginie: with clarification that we would align with IETF CFRG

   <rbarnes> -1

   <selfissued> +1

   <harry> +1

   <bal> +1

   <markw> 0

   <virginie> [+1 agree, -1 object, 0 can live with]

   <nvdbleek> 0

   <virginie> ryan sleevu might object to this one

   <rbarnes> -1 (obo rsleevi)

   0 ( or -0.5)

   <virginie> Option 2 : agreement as a principle to integrate the
   NUMS curves into the WG deliverables, but expect Candidate
   Recommendation to make decision to integrate the algorithm in
   the main spec or as an extension, final set of algorithm would
   align with IETF/CFRG recommendations for TLS deployment

   PROPOSED: Option 2 (see Virginie text)

   harry: Option 2 will probably mean a return to Last Call

   rbarnes: doesn't believe that this is the case

   <rbarnes> it seems like a new LC would be necessary either way

   virginiie: Option 3 may also lead to LC

   <rbarnes> maybe not technically, but it's significant enough

   <harry> Which basically means we have to *explicitly* return to
   this question before exiting CR.

   <harry> It could go back to extension.

   bal: if something is a feature at risk and gets dropped during
   CR, does it get dropped completely or go to an extension

   virginie: that would depend on the participants of the working
   group, could become an extension

   bal: I just want to clarify that it doesn't get dropped

   <selfissued> 0

   virginie: that is the principal of having a road map that we
   are committing to doing this work

   <nvdbleek> 0

   <markw> -0.5

   <bal> 0

   <rbarnes> -0.5

   <harry> 0

   <rbarnes> as in "0 but it would make me sad"


   <rbarnes> -0

   <markw> ah, mine was "-1, but I don't feel really strongly"

   virginie: I'm going to make a call for consensus over the
   mailing list
   ... adding NUMS curves to the main spec is not something that
   we can agree on

   <harry> I mean, it is rather important to determine if -0.5
   means "I can live with but am unhappy"

   markw: it seems possible that we won't get consensus on the
   mailing... if there is no consensus to make a change, then the
   spec stays the same

   virginie: that is my understanding as well

   <harry> You can backoff to votes in exceptional circumstance:


   wseltzer: that could be a way of the working group making a
   decision, would the Director agree that this was a reasonable
   way of making the decision

   virginie: if we can't get consensus we will have to raise the
   issue to the comments, and then the Director will decide

   wseltzer: for all comments, we have to go back to the commenter
   and ask if that satisfies the commenter

   harry: we don't want to do voting, but sometimes we have to,
   and if people aren't happy with the voting, there is a formal
   objection process

   <harry> Alot depends on how long CR takes.

   virginie: another option is delaying our roadmap by six months
   to allow maturity

   <rbarnes> i would object to another 6mo delay

   <markw> No, more delay will not make everyone happy!

   <markw> Pulling out all the EC would be better

   <harry> We could start working on the test-cases regardless of
   CR and LC, but I'd prefer to go into CR as well.

   <rbarnes> we'll see!

   <harry> That's why I proposed "feature at risk" for the
   non-NIST option

   <rbarnes> i would totally +1 to adding a deliverable for

   <rbarnes> just on a different timeline

   virginie: we might have another call in two weeks because I
   would really like to see progress

   <harry> Whether or not timelines sync up is hard to tell at
   this stage in terms of how messy the test-suite will be and how
   TLS/CRFG discussion goes.

   <selfissued> I agree we should have another call and keep
   trying to make these decisions until they're decided

   <markw> I think that (new deliverable) would be a good idea -
   we can develop that whilst still keeping open the option of
   later integration into the main specification

   <harry> When should we do the next call?

   <wseltzer> [25 August, Virginie proposes for next call]

   <harry> August 25th

   <virginie> august 25th

   virginie: next call 25 aug at the same time

   <harry> trackbot, end meeting

On 08/11/2014 11:25 PM, Ryan Sleevi wrote:
> I think the link was dropped?
> You mean ,
> correct?
> On Mon, Aug 11, 2014 at 2:08 PM, GALINDO Virginie < 
>> wrote:
>> (beware, indicative votes about bug 25839 and funny maths
>> inside)
>> Regards,
>> Virginie
>> Chair of the web crypto wg
>> ------------------------------ 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.
Version: GnuPG v1.4.11 (GNU/Linux)


Received on Monday, 11 August 2014 21:28:35 UTC