<wseltzer> trackbot, prepare teleconf

<trackbot> Date: 20 May 2013

<wseltzer> scribenick: rbarnes

hi, i'm richard, and i'll be your scribe today

status on futures

virginie: ryan, any news on futures?

rsleevi: discussion is ongoing

… one of the ongoing issues is cancellation

<rsleevi> http://lists.w3.org/Archives/Public/public-script-coord/2013AprJun/thread.html#msg316

… discussion going on on public-script-coord

… haven't published all of it yet; will address things that have been published as they come up in the agenda

virginie: are you confident that the cancellation aspect will be solved soon?

rsleevi: yes

virginie: will you be able to publish something integrating futures in the beginning of june?

rsleevi: can put up a draft that reflects the api, but would like to hold off and get the algorithm side as well

… have the draft ready, holding off publishing pending the cancellation discussions

… we could push forward if we want to ignore that discussion for the moment, but they're very active

virginie: still hoping to see an editor draft in ~3 jun

<wseltzer> ACTION rsleevi to publish new editor's draft due June 3

<trackbot> Created ACTION-101 - Publish new editor's draft due June 3 [on Ryan Sleevi - due 2013-05-27].

israel: my understanding is that futures are a whatwg concept now, right?

rsleevi: futures as a DOM concept is in whatwg, but futures have been discussed in a couple of w3c WGs

israel: do we expect that there will be a w3c minimal spec on futures, or will we have a dependency on whatwg definitions?

rsleevi: don't have an answer at the moment, would have to see how other groups are doing it

israel: would like to heard about how others in this group feel about referencing whatwg

rsleevi: you've touched on one of the most political issues around, would like to avoid it

… important in any case to make sure we're consistent with webapps

israelh: would hate to see it happen that not having one thing would derail the other

<rsleevi> WebApps announcement thread - http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/1040.html

virginie: would be happy to get feedback from w3c on this question

<wseltzer> ACTION virginie and wendy/harry to get clarity on status of futures

<trackbot> Created ACTION-102 - And wendy/harry to get clarity on status of futures [on Virginie GALINDO - due 2013-05-27].

virginie: rsleevi, any further comments on the spec?

rsleevi: on item 2 or item 3/4

… nothing further on agenda item 2

<rsleevi> https://dvcs.w3.org/hg/webcrypto-api/

virginie: spec in general

rsleevi: actions 90 and 87 have been addressed in that

<wseltzer> ACTION-90?

<trackbot> ACTION-90 -- Ryan Sleevi to add in wrap/unwrap as "feature at risk" to low-level -- due 2013-05-01 -- OPEN

<trackbot> http://www.w3.org/2012/webcrypto/track/actions/90

… action-90 is key wrap/unwrap

… hopefully addresses the netflix use case without being tightly bound to JOSE (format agnostic)

… hopes to support other forms of key transport / wrapping / unwrapping

… expresses a wrapping algorithm, hopefully correct, more general than the netflix case

<wseltzer> ACTION-87?

<trackbot> ACTION-87 -- Ryan Sleevi to update result to be ArrayBuffer than ArrayBufferView -- due 2013-04-30 -- OPEN

<trackbot> http://www.w3.org/2012/webcrypto/track/actions/87

… action-87 changes from ArrayBufferView to ArrayBuffer, hopefully addresses those commetns

… on AB vs. ABV, what i've heard so far is that it's not clear why the specs don't permit either

… next editor draft will probably allow either

virginie: could mark comment on whether he's happy with the wrap/unwrap in the current draft?

markw: just seen the proposal today, so haven't had a chance to review

virginie: ok if we go ahead and close the issue, since wrap has been added? then start another issue on technical quality

<wseltzer> close ISSUE-90

<trackbot> Error closing ISSUE-90 - the response from Tracker was missing data. Please contact sysreq with the details of what happened.

… hearing no objection, we'll close ACTION-90

<wseltzer> RESOLVED: close ACTION-90

<wseltzer> trackbot, close ACTION-90

<trackbot> Closed ACTION-90 Add in wrap/unwrap as "feature at risk" to low-level.

virginie: can we also discuss status on key derivation / agreement / etc. ?

… there was a call last week, summary by vgb on the list

status on key derivation/generation/agreement

vgb: sent an email earlier today, tolga responded

… had a discussion last monday, tried to rule out handling the full variety of key agreement protocols

… focus on a few major two-party protocols

… want it to be possible to write this on top of, say, a hardware module that does the whole thing inside the module

… first major case is DH, second is MQV

… also, derivation to get a number of bytes from the agreed secret

virginie: how confident are you that you will find a stable solution in the next couple weeks?

vgb: well, if nobody proposed changes, it's stable, right?

rsleevi: as part of the deriveKey operation, you're taking public key and private key explicitly

… how much of that is tied to the key agreement scheme you're using?

… trying to find the right level for the API to make sure it's extensible

… my concern is that you're too focused on a few limited use cases

vgb: there's key agreement, and then there's key agreement

… we're focused on the major two-party key agreement

… this is not something like TLS key agreement where we both contribute nonces

… the primitive we're trying to address here is something like DH

… if we try to extend it too much, the concern is that you end up with an extremely generic API that doesn't clearly map to any particular algorithm

rsleevi: there are lots of variants on DH, though

… they agree on Z, then do different things from there

… initial concern is looking at these scoping decisions, and making sure they're not unnecessarily limiting

vgb: the difference between national governments, different DH instances tends to be in terms of group parameters

… the basic math of the DH operation is the same [it just happens in different groups]

… you can layer things like PFS on top of this

… the one thing that's constant is that you have public key / private key for this side / some other stuff

… additional key pairs got lumped into the "other stuff" == algorithm parameters dictionary

… think this is fairly mainstream across all the DH schemes in general use

… there are differences, e.g., in what ECC curves are used, but we

… … are abstracting over that already

… the focus here is getting to Z

rsleevi: agree, the divergence is on how you deal with Z

… the intent of the previous API was to separate out phase 1 and phase 2, where Z is the result of phase 1

… if i understand correctly, you see Z as leaving as a key object, then you derive bytes or keys from it

vgb: right. if you use the same Z with two different KDFs, it's not clear in general that you won't leak information

… this is why the secret key derivation asks the user to tell the API what KDF it's going to use

… trying to make it hard to use two KDFs on the same Z

rsleevi: will take a look, but that was my major concern

vgb: the other open question whether we want something like a "slice" primitive

… richard had suggested something like having "slice" as a KDF algorithm

… my concern was that seemed like it was getting very generic, but interested in hearing other peoples' views

rbarnes: i need to send some more details on that

karen: i understand the use case for slicing, but my concern is that if you generate a long key and generate the next key, the algorithm guarantees the independence of these keys

… however, if you slice, i don't see how you are certain that different parts of the same key satisfy the requirements

vgb: in general, this is part of the KDF algorithms properties, you can use any part of the key stream

… protocols are built to take account of this, e.g., you MUST take bytes X through Y

… so programmers have no alternative

rbarnes: in this case, the "key" that comes out of the KDF isn't a "key" that you would put into an algorithm

… it's an opaque stream of bytes that's held within the module

… from which you then slice out keys and other data

karen: some concerns about FIPS accreditation, need to make sure all the keys meet the criteria

vgb: FIPS specs are OK with this as long as you use non-overlapping slices

… one of the properties of a good KDF is that individual non-overlapping ranges are independent

MichaelH: is the intention that the key size will be derived from the algorithm automatically?

rbarnes: which would you prefer?

MichaelH: seems like automatic would be simpler

rbarnes: but you're going to have to specify the start in any case, and making the developer think about start/end could help avoid overlap

vgb: plus you're going to have to have start/end anyway for algorithms that take arbitrary-length keys

karen: so for deriveKey the output would be a key, but deriveBytes is bytes

vgb: right, the idea is that you use deriveKey to get a key, deriveBytes to get things like nonces

virginie: so discussion will continue on this, then the editor will work on integrating

… like wrap/unwrap, we will integrate into our call in two weeks

dictionary

… next item is the use of dictionaries [10]

rsleevi: the discussion was that if we keep it as a dictionary, we need an explicit method call

… according to WebIDL, you can't have attributes that are dictionaries, they need to return interfaces

… either we have a method like getAlgorithm, or we make interfaces that mirror the algorithm dictionary

… from an implementation side, having the algorithm return dictionaries is no difference

… this is really just spec sugar

… the push that i got was to do the spec sugar to make the WebIDL happy

… israelh, how does that sound?

israelh: that sounds OK, just more interfaces

… thought you had broken up the interface, and returned the dictionary aspect of it

… but that was just in the input parameters, where you ended up taking dictionaries and breaking out individual parameters

rsleevi: nope, don't think so

… that was algorithm vs. algorithm.params, just flattening

israelh: having more interfaces is ok, but were trying to see if there was a simpler way

… this is also associated to the AES-GCM return values

rsleevi: right, would have to return an interface rather than a dictionary

… all the same from the implementation point of view

… this is just a limitation of the expressiveness of WebIDL

israelh: just trying to make sure the right things are implemented based on that spec sugar

rsleevi: right. all the feedback i've gotten says to just write the interfaces

israelh: that seems reasonable

… that's basically what we were proposing for AES-GCM anyway

virginie: so i guess rsleevi will make a proposal?

… wanted to discuss the dates of the next PWD

… rsleevi, if we have futures in two weeks and are able to get comments on wrap/unwrap and agreement/derivation in the next 2 weeks

… then might it be possible to have a PWD in 3 weeks?

rsleevi: don't know if that's reasonable. depends on what we want to do

… we could publish a WD that has some known holes

… that's obviously the case with the current WD, and we're slowly filling them in

… we'll probably reach agreement on the shape of the API, but the specs of the individual steps might not be totally ready

… dictionary vs. interface thing is a good example

… that timeline is pretty tight on time people have to review

virginie: the reason i'm asking is that we haven't published since january or so

… so if we wait until july/august, it's getting kind of long

… let's plan to publish with holes in june, another with fewer holes in august, last call in october

rsleevi: that sounds OK to me. would like others to do more review and identify issues to resolve

… there are obviously a lot of gaps to fill, so we should think about what the most critical gaps are

virginie: so let's try to have the next PWD in june

… and another in august

… wanted to discuss the next f2f

… proposal is in Berlin 25-26 july

… that's the week before the IETF

[thu-fri before the IETF]

<wseltzer> [questionnaire: https://www.w3.org/2002/09/wbs/54174/F2FBerlinJuly13/ ]

… at the moment, the only important person who can't make it is markw

… will be focused on key discovery, high-level thoughts, secondary use cases

… we need to firm things up pretty soon, not completely sure the fraunhofer institute can host

… might try to use IETF venue, will discuss offline

… WASH13 conference is organized by Oxford, will happen on 20th june in london

… about how web apps can be secured with hardware

… nick vdb was accepted and will present some thoughts on web crypto and his experiments with it

… anything else under AOB?

israelh: did we get closure on the question of results for AES-GCM?

… combined or separate?

<virginie> (about WASH'13 http://wash2013.wordpress.com/)

rsleevi: that's a good question. not thrilled with splitting them up, but could probably live with it

… would like to examine what today's APIs do

… part of the concern is to avoid introducing new things

… think we could have the API fake it if the API combines things

… not entirely convinced that it's more intuitive

… but could live with it

… to me, feels less natural rather than more

virginie: do we have an action related to this?

<wseltzer> trackbot, end teleconf

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)

Found ScribeNick: rbarnes
Inferring Scribes: rbarnes
Default Present: +1.617.873.aaaa, jyates, ddahl, Wendy, Israel, Sangrae, Karen, +1.512.257.aabb, +1.512.257.aacc, rsleevi, rbarnes, Virginie, Michael, +1.540.809.aadd, karen_odonoghue, Netflix, [Microsoft], vgb
Present: +1.617.873.aaaa jyates ddahl Wendy Israel Sangrae Karen +1.512.257.aabb +1.512.257.aacc rsleevi rbarnes Virginie Michael +1.540.809.aadd karen_odonoghue Netflix [Microsoft] vgb
Found Date: 20 May 2013
Guessing minutes URL: http://www.w3.org/2013/05/20-crypto-minutes.html
People with action items: 

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