<trackbot> Date: 03 March 2014

<hhalpin> Note that in adminstrivia, sysreq will start copying the bugs to the mailing list this week

<hhalpin> the emails will be from bugzilla@jessica.w3.org

<hhalpin> Hope that helps everyone

<hhalpin> The other note is that we are slowly circling in on a date in Sept. for a possible new workshop

<hhalpin> So I'll throw that out when we have a proper host

<hhalpin> and we'll arrange a telecon.

<virginie> note : aaaa is ryan

<scribe> scribenick: vgb

virginie: open floor for questions to editors

vgb: following up on question around PBKDF and how to use it

rsleevi: we originally talked about linking PBKDF to generateKey (for UI entry of password) but we also need programmatic setting of the password.
... e.g. if you want to do lots of operations you want to have that capability
... possible to define importKey with raw format but in that case you still have to do encoding
... yes we haven't made much progress here. currently with spotty internet working on other issues.

vgb: was proposing last time that we do something like this, and lose the password parameter from KdfParameters.

rsleevi: broadly agree. question of whether we need to expose an export operation.

vgb: don't think it's needed. especially if you go the generateKey route it's counterproductive. just mark the Key non-exportable.

rsleevi: ok. someone open a bug and we'll do this.
... can be done next week if there is a bug filed.
... have import/export defined for most algs, still some holes like generateKey for ECDSA. but at a high level we're mostly looking at editorial issues now.
... style, terminology, etc. so broadly ready for LC. don't know if W3C process allows LC without resolving these minor things.

virginie: we should be okay. it seems like we have everything solved except 2-3 issues as we discussed last week.
... one concern - if we go to LC next week, when will the final ED for that be ready?

rsleevi: final meaning all editorial nits fixed?
... what are we doing on next call? Going to LC, or approving a resolution?

virginie: that was the plan - get a resolution that we're ready for LC.

rsleevi: error codes vs. reject with null is still ongoing discussion. can we carry that to LC?

virginie: having some bugs left is okay as long as issues are sorted out. the rest is interpretation. if we believe we understand how to solve the open question and there is consensus we can proceed.

markw: understand that LC means structurally ready.
... any open bugs we have could also come as LC comments.

virginie: only thing is we need to close all issues. are the current things issues or bugs?

rsleevi: we've been playing fast and loose with those definitions. there is no clear consensus on error codes vs. reject with null. i can see it as a bug but not sure that's the process.

<virginie> reminder : last call rpocess http://www.w3.org/2005/10/Process-20051014/tr.html#last-call

rsleevi: as long as we are comfortable with the idea that backward incompatible changes may yet come, i'm okay.

virginie: feel we can go to LC.

markw: we're ready for implementation, so we should go to LC.

israelh: nowadays implementations are coming alive before CR. so we should address implementation issues now. so if we can't agree on basic things we should not go to LC.
... we should have things together before going to LC. we need to say for sure this is what we want implementers to do.

virginie: anything in the current spec that's uncomfortable to you?

israelh: i thought exception handling was a closed issue.

rsleevi: this is different. no exceptions, just rejecting promises. the issue however is whether to reject with null or with an exception code. see list discussion and feedback from blink and webkit implementers.
... e.g. what if you try an invalid hash name? Alexei proposed you reject with a syntax error. and so on.
... this makes it easier for developers to understand what is going wrong.
... this is what is outstanding. what error type to use?

israelh: so you're saying promises framework doesn't address this issue by itself.

rsleevi: same problem with event model. what error does onError get?

israelh: sounds to me like this is something we should wait to define before LC. this is the kind of thing we should have a clear stance on.

rsleevi: yes, we are still discussing and why i said this is still open.

israelh: based on that, don't want to go to LC until we have some baseline understanding on the error type at least.

virginie: so then we hav a clear decision that we will not ask for LC next week. delay that until we can clarify this. so what do people need in order to progress on this?

rsleevi: we've been discussing on the list. trying to nail down the mapping and inheritance. there is a proposal on the list.
... need feedback on the ontology. can't distinguish every possible error, so need to decide how many errors we will collapse things into.
... need consensus from implementers and potential consumers of the API.

markw: don't feel this issue should delay LC. we should try and resolve it this week so we can move on to LC next week.

virginie: need to make sure we close the issue, don't want to put pressure. so if we can fix things this week then maybe we can afford to postpone to the next call.

markw: we're way late already. let's just put a note in the spec and go to LC so we can get public feedback.
... it's clear the promise gets rejected, the rest is figuring out how many errors we define.

rsleevi: my understanding of the process is similar to israel's. LC should mean we have our spec together. this issue has been lingering for a while, but now is one of the first things developers and implementers will ask for.

markw: if we decide this week that we will reject the promise and we don't yet know if we have 3 errors or 7, should that block LC?
... that seems extremely minor and not worth more delay.

israelh: looking through thread now. i think if we had an initial set that we said we were initially comfortable with then we could proceed with that as a baseline.
... but going forward saying we don't know if we'll return null or an object seems wrong. fine tuning is okay.
... we don't want to rush into LC and be forced to another LC.

markw: is there anyone still arguing for returning null?

all: <crickets>

rsleevi: think we are in consensus that we want to return errors. don't know how it's going to look collectively and if the errors make sense.
... i am convinced though that we are going to have another LC given how things are going.
... maybe we are better served by another working draft, but if we are going to LC we should prepare for another LC,

virginie: see that there is a real problem people want to address. so propose we delay the LC decision by a week, and wait for people to reach a conclusion on errors.

markw: believe that we have clearly reached consensus that we should not reject with null.
... so this is now just fine tuning.

israelh: agree with mark. maybe we (the implementers) could proceed with this consensus. we have some precedent, e.g. IndexedDB. if we can say in this call that it's enough to proceed, then by next week we can check for consensus on the initial error set.
... if we can close on the list next week, then we can go to LC from there.

virginie: do you think we can be ready for a decision on march 10?

israelh: if we can reach a conclusion this week, sure. if we decide to surface the errors and have an agreed-upon common set, then we should be set.

rsleevi: we have something like that on the list. so what needs to be done is for people to look at the spec with that list in mind and provide feedback. we have that starting point for dicsussion.

israelh: would prefer a formal table that defines this.
... bug number 24813, last email thread on the bug has lots of questions.
... was hoping to see a clearer statement of what the errors are and when they will be reported.

<virginie> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24813

rsleevi: look at Alexei's email sent february 28 @12:02 PT (GMT - 8).

<virginie> http://lists.w3.org/Archives/Public/public-webcrypto/2014Mar/0003.html

rsleevi: that gives us 3 maybe 5 errors. seems like a good starting point.

israelh: ok, see that now. can give feedback this week.

virginie: would like to get feedback by friday so we can have time for editors to update the doc.
... so we should be able to decide by friday if we should go to the LC decision monday.

markw: people can see updates so maybe this isn't such an issue?

rsleevi: still, should be careful. sometimes looking at isolated changes misses context.

virginie: can we have a decision monday if we have a stable version friday?

rsleevi: seems tight, people may not be able to review on the weekend.

israelh: should be able to send out feedback tuesday or wednesday.

markw: can spend time editing on wednesday so we can have a version that day.

virginie: need to inform others that this issue is being worked on. will send email to list.
... looks like we are fine with respect to other bugs.
... any other topics?

markw: question with HKDF-CTR alg. which reference should we use? RFC 5869 or SP 800-108. Need to decide which.

rsleevi: implementation status? what does JOSE use?

vgb: ... CNG implements 800-108, think JOSE uses that as well. Not sure if JOSE does RFC 5869.

virginie: seems like we should do 800-108 then.

markw: should we mandate min key length for HMAC?
... zero length keys?

vgb: don't care. not sure 1-byte keys are that much more secure than 0-byte keys. underlying implementations will have restrictions anyways.

rsleevi: agree. do have a problem with limiting key length to L/2, that is not suitable especially since it should be okay to use SHA512 to derive 128-bit keys.

markw: if we allow import of 0-length keys then maybe export should allow this too for symmatry?

rsleevi: don't care. could work around in implementation or specify it in the doc. not a blocker.

virginie: thanks all. will maintain proposal to go for LC decision next week based on error feedback this week. bye!

<hhalpin> trackbot, end meeting

<trackbot> Chair: Virginie Galindo