<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> http://www.w3.org/2005/10/Process-20051014/tr#cfi

<wseltzer> services.w3.org/xslt?xmlfile=http://www.w3.org/2005/08/01-transitions.html&xslfile=http://www.w3.org/2005/08/transitions.xsl&docstatus=cr-trza

<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 Director

<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 closed?

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 https://www.w3.org/Bugs/Public/show_bug.cgi?id=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)

<wseltzer> http://lists.w3.org/Archives/Public/public-webcrypto/2014Aug/0083.html

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 recommendations

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 specification
... 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 consensus
... 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 https://www.w3.org/Bugs/Public/buglist.cgi?quicksearch=web%20crypto&list_id=42092

<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 plug=ins
... 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 sense.

<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

+1

<bal> -1

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

<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 completely

<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"

-0.5

<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: http://www.w3.org/2014/Process-20140801/#Votes

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 non-NIST

<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

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/ack16:50 < kodonog> virginiie: Option 3 may also lead to LC//
Found ScribeNick: kodonog
Found Scribe: kodonog
Inferring ScribeNick: kodonog
Default Present: Wendy, JYates, virginie, BAL, markw, [Microsoft], +1.503.712.aaaa, selfissued, Matt_Wood, hhalpin, karen_oDonoghue, vgb, nvdbleek_, rbarnes
Present: Wendy JYates virginie BAL markw [Microsoft] +1.503.712.aaaa selfissued Matt_Wood hhalpin karen_oDonoghue vgb nvdbleek_ rbarnes
Regrets: rsleevi

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 11 Aug 2014
Guessing minutes URL: http://www.w3.org/2014/08/11-crypto-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.