See also: IRC log
<wseltzer> trackbot, prepare teleconf
<trackbot> Date: 20 May 2013
<wseltzer> scribenick: rbarnes
hi, i'm richard, and i'll be your scribe today
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
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
… 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.[End of scribe.perl diagnostic output]