19:45:24 <RRSAgent> RRSAgent has joined #crypto
19:45:24 <RRSAgent> logging to http://www.w3.org/2013/05/20-crypto-irc
19:47:44 <virginie> Zakim, this will be webcrypto
19:47:44 <Zakim> I do not see a conference matching that name scheduled within the next hour, virginie
19:48:09 <virginie> Zakim, this will be webcrypto
19:48:09 <Zakim> I do not see a conference matching that name scheduled within the next hour, virginie
19:48:17 <virginie> Zakim, this will be crypto
19:48:17 <Zakim> I do not see a conference matching that name scheduled within the next hour, virginie
19:54:23 <rbarnes> rbarnes has joined #crypto
19:56:33 <wseltzer> zakim, this will be CRYPT
19:56:33 <Zakim> ok, wseltzer; I see SEC_WebCryp()4:00PM scheduled to start in 4 minutes
19:56:33 <sangrae> sangrae has joined #crypto
19:56:39 <wseltzer> trackbot, prepare teleconf
19:56:41 <trackbot> RRSAgent, make logs public
19:56:43 <trackbot> Zakim, this will be SEC_WebCryp
19:56:43 <Zakim> ok, trackbot, I see SEC_WebCryp()4:00PM already started
19:56:44 <trackbot> Meeting: Web Cryptography Working Group Teleconference
19:56:44 <trackbot> Date: 20 May 2013
19:57:46 <virginie> Chair: virginie
19:58:12 <virginie> agenda ?
19:58:41 <Zakim> +jyates
19:58:53 <virginie> agenda+ welcome
19:59:04 <virginie> agenda+ status on futures
19:59:10 <karen> karen has joined #crypto
19:59:12 <Zakim> +[IPcaller]
19:59:37 <virginie> agenda+ status on key derivation/generation/agreement
19:59:47 <Zakim> +ddahl
19:59:50 <virginie> agenda+ status on key wrap/unwrap
20:00:02 <virginie> agenda+ action followup
20:00:11 <Zakim> +Wendy
20:00:17 <Zakim> +[Microsoft]
20:00:22 <virginie> agenda+ next PWD
20:00:31 <virginie> agenda+ status on use cases
20:00:39 <wseltzer> zakim, Microsoft has Israel
20:00:39 <Zakim> +Israel; got it
20:00:41 <virginie> agenda+ next F2F meeting
20:00:47 <israelh> israelh has joined #crypto
20:00:57 <virginie> agenda+ AOB (WASH13, ...)
20:01:10 <MichaelH> MichaelH has joined #crypto
20:01:14 <Zakim> +Google
20:01:44 <Zakim> +Karen
20:01:45 <Zakim> + +1.512.257.aabb
20:01:57 <karen_odonoghue> karen_odonoghue has joined #crypto
20:01:59 <Zakim> + +1.512.257.aacc
20:02:08 <rbarnes> zakim, who's on the phone?
20:02:08 <Zakim> On the phone I see +1.617.873.aaaa, jyates, Sangrae, ddahl, Wendy, [Microsoft], Google, Karen, +1.512.257.aabb, +1.512.257.aacc
20:02:10 <karen> zakim, aabb is Karen
20:02:11 <Zakim> [Microsoft] has Israel
20:02:11 <Zakim> +Karen; got it
20:02:13 <rbarnes> zakim, i am aaaa
20:02:13 <Zakim> +rbarnes; got it
20:02:45 <virginie> zakim, who is on the phone ?
20:02:45 <Zakim> On the phone I see rbarnes, jyates, Sangrae, ddahl, Wendy, [Microsoft], Google, Karen, Karen.a, Virginie
20:02:48 <Zakim> [Microsoft] has Israel
20:02:48 <Zakim> Google has rsleevi
20:02:54 <wseltzer> zakim, Karen.a is really Michael
20:02:54 <Zakim> +Michael; got it
20:02:57 <Zakim> + +1.540.809.aadd
20:03:18 <wseltzer> zakim, aadd is kodonog
20:03:18 <Zakim> +kodonog; got it
20:03:18 <virginie> zakim, who is on the phone ?
20:03:19 <Zakim> On the phone I see rbarnes, jyates, Sangrae, ddahl, Wendy, [Microsoft], Google, Karen, Michael, Virginie, kodonog
20:03:19 <Zakim> [Microsoft] has Israel
20:03:19 <Zakim> Google has rsleevi
20:04:02 <virginie> agenda?
20:04:06 <wseltzer> zakim, kodonog is really karen_odonoghue
20:04:06 <Zakim> +karen_odonoghue; got it
20:05:37 <markw> markw has joined #crypto
20:05:52 <wseltzer> agenda+ dictionary
20:06:13 <wseltzer> scribenick: rbarnes
20:06:20 <rbarnes> hi, i'm richard, and i'll be your scribe today
20:06:59 <wseltzer> zakim, take up agendum 2
20:06:59 <Zakim> agendum 2. "status on futures" taken up [from virginie]
20:07:14 <rbarnes> virginie: ryan, any news on futures?
20:07:22 <rbarnes> rsleevi: discussion is ongoing
20:07:34 <rbarnes> … one of the ongoing issues is cancellation
20:07:37 <rsleevi> http://lists.w3.org/Archives/Public/public-script-coord/2013AprJun/thread.html#msg316
20:07:41 <rbarnes> … discussion going on on public-script-coord
20:08:38 <eroman> eroman has joined #crypto
20:08:43 <rbarnes> … haven't published all of it yet; will address things that have been published as they come up in the agenda
20:08:56 <rbarnes> virginie: are you confident that the cancellation aspect will be solved soon?
20:08:59 <rbarnes> rsleevi: yes
20:09:16 <rbarnes> virginie: will you be able to publish something integrating futures in the beginning of june?
20:09:36 <rbarnes> rsleevi: can put up a draft that reflects the api, but would like to hold off and get the algorithm side as well
20:09:45 <Zakim> +Netflix
20:09:55 <rbarnes> … have the draft ready, holding off publishing pending the cancellation discussions
20:10:19 <vgb> vgb has joined #crypto
20:10:20 <rbarnes> … we could push forward if we want to ignore that discussion for the moment, but they're very active
20:10:46 <Zakim> +[Microsoft.a]
20:10:52 <rbarnes> virginie: still hoping to see an editor draft in ~3 jun
20:10:58 <vgb> zakim, [microsoft.a] is me
20:10:58 <Zakim> +vgb; got it
20:11:00 <wseltzer> ACTION rsleevi to publish new editor's draft due June 3
20:11:00 <trackbot> Created ACTION-101 - Publish new editor's draft due June 3 [on Ryan Sleevi - due 2013-05-27].
20:11:35 <rbarnes> israel: my understanding is that futures are a whatwg concept now, right?
20:12:00 <rbarnes> rsleevi: futures as a DOM concept is in whatwg, but futures have been discussed in a couple of w3c WGs
20:12:29 <rbarnes> israel: do we expect that there will be a w3c minimal spec on futures, or will we have a dependency on whatwg definitions?
20:12:43 <rbarnes> rsleevi: don't have an answer at the moment, would have to see how other groups are doing it
20:13:02 <rbarnes> israel: would like to heard about how others in this group feel about referencing whatwg
20:13:15 <virginie> q?
20:13:17 <rbarnes> rsleevi: you've touched on one of the most political issues around, would like to avoid it
20:13:39 <rbarnes> … important in any case to make sure we're consistent with webapps
20:13:56 <rbarnes> israelh: would hate to see it happen that not having one thing would derail the other
20:14:09 <rsleevi> WebApps announcement thread - http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/1040.html
20:14:14 <rbarnes> virginie: would be happy to get feedback from w3c on this question
20:14:45 <wseltzer> ACTION virginie and wendy/harry to get clarity on status of futures
20:14:45 <trackbot> Created ACTION-102 - And wendy/harry to get clarity on status of futures [on Virginie GALINDO - due 2013-05-27].
20:15:24 <virginie> agenda?
20:15:56 <rbarnes> virginie: rsleevi, any further comments on the spec?
20:16:03 <rbarnes> rsleevi: on item 2 or item 3/4
20:16:15 <rbarnes> … nothing further on agenda item 2
20:16:23 <rsleevi> https://dvcs.w3.org/hg/webcrypto-api/
20:16:25 <rbarnes> virginie: spec in general
20:16:40 <rbarnes> rsleevi: actions 90 and 87 have been addressed in that
20:17:04 <wseltzer> ACTION-90?
20:17:04 <trackbot> ACTION-90 -- Ryan Sleevi to add in wrap/unwrap as "feature at risk" to low-level -- due 2013-05-01 -- OPEN
20:17:04 <trackbot> http://www.w3.org/2012/webcrypto/track/actions/90
20:17:23 <rbarnes> … action-90 is key wrap/unwrap
20:17:44 <rbarnes> … hopefully addresses the netflix use case without being tightly bound to JOSE (format agnostic)
20:18:12 <rbarnes> … hopes to support other forms of key transport / wrapping / unwrapping
20:18:38 <rbarnes> … expresses a wrapping algorithm, hopefully correct, more general than the netflix case
20:18:42 <wseltzer> ACTION-87?
20:18:42 <trackbot> ACTION-87 -- Ryan Sleevi to update result to be ArrayBuffer than ArrayBufferView -- due 2013-04-30 -- OPEN
20:18:42 <trackbot> http://www.w3.org/2012/webcrypto/track/actions/87
20:19:07 <rbarnes> … action-87 changes from ArrayBufferView to ArrayBuffer, hopefully addresses those commetns
20:19:43 <rbarnes> … on AB vs. ABV, what i've heard so far is that it's not clear why the specs don't permit either
20:19:52 <rbarnes> … next editor draft will probably allow either
20:20:26 <markw> q+
20:20:29 <rbarnes> virginie: could mark comment on whether he's happy with the wrap/unwrap in the current draft?
20:20:43 <rbarnes> markw: just seen the proposal today, so haven't had a chance to review
20:21:14 <rbarnes> virginie: ok if we go ahead and close the issue, since wrap has been added?  then start another issue on technical quality
20:21:31 <wseltzer> close ISSUE-90
20:21:31 <trackbot> Error closing ISSUE-90 - the response from Tracker was missing data. Please contact sysreq with the details of what happened.
20:21:35 <rbarnes> … hearing no objection, we'll close ACTION-90
20:22:03 <wseltzer> RESOLVED: close ACTION-90
20:22:19 <wseltzer> trackbot, close ACTION-90
20:22:20 <trackbot> Closed ACTION-90 Add in wrap/unwrap as "feature at risk" to low-level.
20:22:22 <rbarnes> virginie: can we also discuss status on key derivation / agreement / etc. ?
20:22:33 <rbarnes> … there was a call last week, summary by vgb on the list
20:22:38 <wseltzer> zakim, take up agendum 3
20:22:38 <Zakim> agendum 3. "status on key derivation/generation/agreement" taken up [from virginie]
20:23:06 <rbarnes> vgb: sent an email earlier today, tolga responded
20:23:23 <rbarnes> … had a discussion last monday, tried to rule out handling the full variety of key agreement protocols
20:23:33 <rbarnes> … focus on a few major two-party protocols
20:24:04 <rbarnes> … want it to be possible to write this on top of, say, a hardware module that does the whole thing inside the module
20:24:15 <rbarnes> … first major case is DH, second is MQV
20:24:21 <virginie> q?
20:24:34 <markw> q-
20:24:34 <rbarnes> … also, derivation to get a number of bytes from the agreed secret
20:25:07 <rsleevi> q+
20:25:20 <rbarnes> virginie: how confident are you that you will find a stable solution in the next couple weeks?
20:25:32 <rbarnes> vgb: well, if nobody proposed changes, it's stable, right?
20:25:56 <rbarnes> rsleevi: as part of the deriveKey operation, you're taking public key and private key explicitly
20:26:05 <rbarnes> … how much of that is tied to the key agreement scheme you're using?
20:26:14 <rbarnes> … trying to find the right level for the API to make sure it's extensible
20:26:26 <rbarnes> … my concern is that you're too focused on a few limited use cases
20:26:37 <rbarnes> vgb: there's key agreement, and then there's key agreement
20:26:55 <rbarnes> … we're focused on the major two-party key agreement
20:27:05 <rbarnes> … this is not something like TLS key agreement where we both contribute nonces
20:27:16 <rbarnes> … the primitive we're trying to address here is something like DH
20:27:54 <rbarnes> … 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
20:28:13 <rbarnes> rsleevi: there are lots of variants on DH, though
20:28:19 <rbarnes> … they agree on Z, then do different things from there
20:28:50 <rbarnes> … initial concern is looking at these scoping decisions, and making sure they're not unnecessarily limiting
20:29:08 <rbarnes> vgb: the difference between national governments, different DH instances tends to be in terms of group parameters
20:29:21 <rbarnes> … the basic math of the DH operation is the same [it just happens in different groups]
20:29:35 <rbarnes> … you can layer things like PFS on top of this
20:29:57 <rbarnes> … the one thing that's constant is that you have public key / private key for this side / some other stuff
20:30:22 <rbarnes> … additional key pairs got lumped into the "other stuff" == algorithm parameters dictionary
20:30:33 <rbarnes> … think this is fairly mainstream across all the DH schemes in general use
20:30:50 <rbarnes> … there are differences, e.g., in what ECC curves are used, but we
20:30:57 <rbarnes> …  … are abstracting over that already
20:31:02 <rbarnes> … the focus here is getting to Z
20:31:20 <rbarnes> rsleevi: agree, the divergence is on how you deal with Z
20:31:34 <rbarnes> … the intent of the previous API was to separate out phase 1 and phase 2, where Z is the result of phase 1
20:32:06 <rbarnes> … if i understand correctly, you see Z as leaving as a key object, then you derive bytes or keys from it
20:32:39 <rbarnes> vgb: right.  if you use the same Z with two different KDFs, it's not clear in general that you won't leak information
20:33:06 <rbarnes> … this is why the secret key derivation asks the user to tell the API what KDF it's going to use
20:33:14 <rbarnes> … trying to make it hard to use two KDFs on the same Z
20:33:25 <rbarnes> rsleevi: will take a look, but that was my major concern
20:34:02 <rbarnes> vgb: the other open question whether we want something like a "slice" primitive
20:34:17 <rbarnes> … richard had suggested something like having "slice" as a KDF algorithm
20:34:34 <rbarnes> … my concern was that seemed like it was getting very generic, but interested in hearing other peoples' views
20:34:42 <karen> q+
20:34:52 <rbarnes> rbarnes: i need to send some more details on that
20:35:29 <rbarnes> 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
20:35:46 <rbarnes> … however, if you slice, i don't see how you are certain that different parts of the same key satisfy the requirements
20:36:08 <rbarnes> vgb: in general, this is part of the KDF algorithms properties, you can use any part of the key stream
20:36:21 <rbarnes> … protocols are built to take account of this, e.g., you MUST take bytes X through Y
20:36:27 <rbarnes> … so programmers have no alternative
20:37:21 <rbarnes> rbarnes: in this case, the "key" that comes out of the KDF isn't a "key" that you would put into an algorithm
20:37:31 <rbarnes> … it's an opaque stream of bytes that's held within the module
20:37:47 <rbarnes> … from which you then slice out keys and other data
20:38:08 <rbarnes> karen: some concerns about FIPS accreditation, need to make sure all the keys meet the criteria
20:38:21 <rbarnes> vgb: FIPS specs are OK with this as long as you use non-overlapping slices
20:38:34 <rbarnes> … one of the properties of a good KDF is that individual non-overlapping ranges are independent
20:38:50 <MichaelH> q+
20:39:06 <wseltzer> q- karen
20:39:09 <wseltzer> q- MichaelH
20:39:29 <rbarnes> MichaelH: is the intention that the key size will be derived from the algorithm automatically?
20:40:27 <rbarnes> rbarnes: which would you prefer?
20:40:36 <rbarnes> MichaelH: seems like automatic would be simpler
20:40:47 <karen> q+
20:40:55 <rbarnes> 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
20:41:00 <wseltzer> ack kar
20:41:14 <rbarnes> vgb: plus you're going to have to have start/end anyway for algorithms that take arbitrary-length keys
20:41:30 <rbarnes> karen: so for deriveKey the output would be a key, but deriveBytes is bytes
20:41:53 <rbarnes> vgb: right, the idea is that you use deriveKey to get a key, deriveBytes to get things like nonces
20:42:16 <rbarnes> virginie: so discussion will continue on this, then the editor will work on integrating
20:42:29 <rbarnes> … like wrap/unwrap, we will integrate into our call in two weeks
20:42:57 <wseltzer> zakim, take up agendum 10
20:42:57 <Zakim> agendum 10. "dictionary" taken up [from wseltzer]
20:42:58 <rbarnes> … next item is the use of dictionaries [10]
20:43:35 <rbarnes> rsleevi: the discussion was that if we keep it as a dictionary, we need an explicit method call
20:43:47 <rbarnes> … according to WebIDL, you can't have attributes that are dictionaries, they need to return interfaces
20:44:06 <rbarnes> … either we have a method like getAlgorithm, or we make interfaces that mirror the algorithm dictionary
20:44:07 <rbarnes> q+
20:44:25 <virginie> zakim, who is on the phone ?
20:44:25 <Zakim> On the phone I see rbarnes, jyates, Sangrae, ddahl, Wendy, [Microsoft], Google, Karen, Michael, Virginie, karen_odonoghue, Netflix, vgb
20:44:27 <Zakim> [Microsoft] has Israel
20:44:27 <Zakim> Google has rsleevi
20:44:28 <rbarnes> … from an implementation side, having the algorithm return dictionaries is no difference
20:44:36 <rbarnes> … this is really just spec sugar
20:45:04 <rbarnes> … the push that i got was to do the spec sugar to make the WebIDL happy
20:45:12 <rbarnes> … israelh, how does that sound?
20:45:20 <rbarnes> israelh: that sounds OK, just more interfaces
20:45:21 <rbarnes> q-
20:45:37 <rbarnes> … thought you had broken up the interface, and returned the dictionary aspect of it
20:45:56 <rbarnes> … but that was just in the input parameters, where you ended up taking dictionaries and breaking out individual parameters
20:46:03 <rbarnes> rsleevi: nope, don't think so
20:46:25 <rbarnes> … that was algorithm vs. algorithm.params, just flattening
20:46:46 <rbarnes> israelh: having more interfaces is ok, but were trying to see if there was a simpler way
20:47:00 <rbarnes> … this is also associated to the AES-GCM return values
20:47:13 <rbarnes> rsleevi: right, would have to return an interface rather than a dictionary
20:47:20 <rbarnes> … all the same from the implementation point of view
20:47:38 <rbarnes> … this is just a limitation of the expressiveness of WebIDL
20:47:53 <rbarnes> israelh: just trying to make sure the right things are implemented based on that spec sugar
20:48:05 <rbarnes> rsleevi: right.  all the feedback i've gotten says to just write the interfaces
20:48:26 <rbarnes> israelh: that seems reasonable
20:48:38 <rbarnes> … that's basically what we were proposing for AES-GCM anyway
20:49:30 <rbarnes> virginie: so i guess rsleevi will make a proposal?
20:49:44 <rbarnes> … wanted to discuss the dates of the next PWD
20:50:21 <rbarnes> … 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
20:50:31 <rbarnes> … then might it be possible to have a PWD in 3 weeks?
20:50:44 <rbarnes> rsleevi: don't know if that's reasonable.  depends on what we want to do
20:50:52 <rbarnes> … we could publish a WD that has some known holes
20:51:08 <rbarnes> … that's obviously the case with the current WD, and we're slowly filling them in
20:51:25 <rbarnes> … we'll probably reach agreement on the shape of the API, but the specs of the individual steps might not be totally ready
20:51:41 <rbarnes> … dictionary vs. interface thing is a good example
20:52:11 <rbarnes> … that timeline is pretty tight on time people have to review
20:52:44 <rbarnes> virginie: the reason i'm asking is that we haven't published since january or so
20:52:55 <rbarnes> … so if we wait until july/august, it's getting kind of long
20:53:20 <rbarnes> … let's plan to publish with holes in june, another with fewer holes in august, last call in october
20:53:38 <rbarnes> rsleevi: that sounds OK to me.  would like others to do more review and identify issues to resolve
20:53:55 <rbarnes> … there are obviously a lot of gaps to fill, so we should think about what the most critical gaps are
20:54:26 <rbarnes> virginie: so let's try to have the next PWD in june
20:54:32 <rbarnes> … and another in august
20:54:50 <rbarnes> … wanted to discuss the next f2f
20:55:15 <rbarnes> … proposal is in Berlin 25-26 july
20:55:22 <rbarnes> … that's the week before the IETF
20:55:37 <rbarnes> [thu-fri before the IETF]
20:55:44 <wseltzer> [questionnaire: https://www.w3.org/2002/09/wbs/54174/F2FBerlinJuly13/ ]
20:55:54 <rbarnes> … at the moment, the only important person who can't make it is markw
20:56:29 <rbarnes> … will be focused on key discovery, high-level thoughts, secondary use cases
20:57:55 <rbarnes> … we need to firm things up pretty soon, not completely sure the fraunhofer institute can host
20:58:10 <rbarnes> … might try to use IETF venue, will discuss offline
20:58:55 <rbarnes> … WASH13 conference is organized by Oxford, will happen on 20th june in london
20:59:09 <rbarnes> … about how web apps can be secured with hardware
20:59:37 <rbarnes> … nick vdb was accepted and will present some thoughts on web crypto and his experiments with it
21:00:05 <rbarnes> … anything else under AOB?
21:00:20 <rbarnes> israelh: did we get closure on the question of results for AES-GCM?
21:00:24 <rsleevi> q+
21:00:28 <rbarnes> … combined or separate?
21:00:39 <virginie> (about WASH'13 http://wash2013.wordpress.com/)
21:01:08 <rbarnes> rsleevi: that's a good question.  not thrilled with splitting them up, but could probably live with it
21:01:21 <rbarnes> … would like to examine what today's APIs do
21:01:44 <rbarnes> … part of the concern is to avoid introducing new things
21:01:52 <rbarnes> … think we could have the API fake it if the API combines things
21:01:58 <rbarnes> … not entirely convinced that it's more intuitive
21:02:03 <rbarnes> … but could live with it
21:02:14 <rbarnes> … to me, feels less natural rather than more
21:02:24 <rbarnes> virginie: do we have an action related to this?
21:03:13 <Zakim> -Google
21:03:24 <Zakim> -Netflix
21:03:25 <Zakim> -jyates
21:03:26 <Zakim> -ddahl
21:03:33 <Zakim> -Karen
21:03:35 <Zakim> -Wendy
21:03:37 <Zakim> -[Microsoft]
21:03:38 <Zakim> -karen_odonoghue
21:03:38 <Zakim> -vgb
21:03:40 <Zakim> -Virginie
21:03:47 <Zakim> -Sangrae
21:03:56 <MichaelH> MichaelH has left #crypto
21:04:05 <Zakim> -rbarnes
21:35:01 <Zakim> disconnecting the lone participant, Michael, in SEC_WebCryp()4:00PM
21:35:03 <Zakim> SEC_WebCryp()4:00PM has ended
21:35:03 <Zakim> Attendees were +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,
21:35:03 <Zakim> ... karen_odonoghue, Netflix, [Microsoft], vgb
23:53:29 <wseltzer> trackbot, end teleconf
23:53:29 <trackbot> Zakim, list attendees
23:53:29 <Zakim> sorry, trackbot, I don't know what conference this is
23:53:37 <trackbot> RRSAgent, please draft minutes
23:53:37 <RRSAgent> I have made the request to generate http://www.w3.org/2013/05/20-crypto-minutes.html trackbot
23:53:38 <trackbot> RRSAgent, bye
23:53:38 <RRSAgent> I see no action items