20:03:21 <RRSAgent> RRSAgent has joined #crypto
20:03:21 <RRSAgent> logging to http://www.w3.org/2013/05/13-crypto-irc
20:03:23 <trackbot> RRSAgent, make logs public
20:03:25 <trackbot> Zakim, this will be SEC_WebCryp
20:03:25 <Zakim> ok, trackbot, I see SEC_WebCryp()4:00PM already started
20:03:26 <trackbot> Meeting: Web Cryptography Working Group Teleconference
20:03:26 <trackbot> Date: 13 May 2013
20:03:37 <Zakim> +??P10
20:03:53 <vgb> zakim, [microsoft] is me
20:03:53 <Zakim> +vgb; got it
20:03:54 <scottk> scottk has joined #crypto
20:03:55 <rbarnes> zakim, who is on the phone?
20:03:55 <Zakim> On the phone I see ddahl, +1.540.809.aaaa, +1.857.928.aabb, +1.408.458.aacc, +1.512.257.aadd, Rich_Schwerdtfeger, vgb, Wendy, ??P10
20:03:55 <hhalpin> Zakim, pick a scribe
20:03:57 <Zakim> Not knowing who is chairing or who scribed recently, I propose vgb
20:04:04 <jyates> Zakim, aabb is jyates
20:04:04 <Zakim> +jyates; got it
20:04:05 <rbarnes> azkim, i am ??P10
20:04:05 <hhalpin> Zakim, ??P10 is hhalpin
20:04:06 <Zakim> +hhalpin; got it
20:04:23 <hhalpin> chair: hhalpin
20:04:26 <vgb> scribenick: vgb
20:04:31 <hhalpin> topic: key lifecycle and key agreement meeting
20:04:55 <hhalpin> anyone want to step forward with a proposal on best way forward?
20:05:02 <hhalpin> it seems key agreement is needed :)
20:05:05 <karen> Zakim, aadd is Karen
20:05:05 <Zakim> +Karen; got it
20:05:09 <wseltzer> action-84?
20:05:09 <trackbot> ACTION-84 -- Richard Barnes to vgb and jimsch to discuss key generation/derivation/agreement -- due 2013-05-21 -- OPEN
20:05:09 <trackbot> http://www.w3.org/2012/webcrypto/track/actions/84
20:05:21 <rbarnes> zakim, who is on the phone?
20:05:21 <Zakim> On the phone I see ddahl, +1.540.809.aaaa, jyates, +1.408.458.aacc, Karen, Rich_Schwerdtfeger, vgb, Wendy, hhalpin
20:05:28 <vgb> hhalpin: what are we doing here?
20:05:31 <rbarnes> hm, i'm not accounted for in the "on the phone" list
20:05:44 <vgb> vgb: ACTION 84
20:05:44 <markw> markw has joined #crypto
20:05:45 <wseltzer> present+ rbarnes
20:06:00 <jimsch> I am still not getting a valid pass coe - so irc only
20:06:03 <mitchz> mitchz has joined #crypto
20:06:05 <hhalpin> deriveKey
20:06:11 <hhalpin> flagged unclear it's the best way is way
20:06:18 <rbarnes> also, i've been pretty much offline for the last week, so i'm probably unaware of things that have happened that recently
20:06:20 <vgb> hhalpin: need to make decision on how to do key agreement
20:06:23 <hhalpin> I'm pretty sure key agreement is *not* in spec
20:06:30 <hhalpin> These seem like basic primitives
20:06:46 <jimsch> That what I was trying.
20:06:51 <hhalpin> Zakim, pick a scribe
20:06:51 <Zakim> Not knowing who is chairing or who scribed recently, I propose Wendy
20:07:00 <hhalpin> wendy?
20:07:15 <Zakim> +Netflix
20:07:27 <hhalpin> Zakim, pick a scribe
20:07:27 <Zakim> Not knowing who is chairing or who scribed recently, I propose vgb
20:07:29 <hhalpin> Zakim, pick a scribe
20:07:29 <Zakim> Not knowing who is chairing or who scribed recently, I propose Rich_Schwerdtfeger
20:07:31 <hhalpin> Zakim, pick a scribe
20:07:31 <Zakim> Not knowing who is chairing or who scribed recently, I propose ddahl
20:07:36 <hhalpin> David?
20:07:54 <wseltzer> scribenick: wseltzer
20:08:28 <wseltzer> hhalpin: Goal, concrete proposal on key agreement to make formal proposal to go into next version of the spec
20:08:38 <wseltzer> vgb: Sent an email earlier today
20:09:10 <wseltzer> ... what we're trying to do: I'd be happy to cover DH and MQV
20:09:24 <wseltzer> ... finite fields and elliptic curves.
20:09:38 <wseltzer> ... Start with simple cases.
20:10:21 <wseltzer> ... Value in having a derivekey method, but given how many use KDF as generic, need derivebytes
20:10:46 <wseltzer> ... so email made two proposals: derivebytes, and secret agreement
20:10:54 <rbarnes> this may be a dumb idea, but could we just have polymorphism between ArrayBufferView and Key == ABV inside the envelope ?
20:11:16 <wseltzer> ... take set of key handles, output a key handle
20:11:51 <wseltzer> @@: so you mean we'd do keyAgreement, then deriveBytes?
20:12:08 <wseltzer> vgb: you don't get to see the key directly, just the derived bytes
20:12:42 <hhalpin> deriveKey and deriveBytes are separate
20:13:01 <hhalpin> +1
20:13:10 <wseltzer> vgb: encourage good practice, by not stepping out of the envelope unless necessary
20:13:46 <wseltzer> rbarnes: what about case where app wants to derive multiple things from octets from keyAgreement?
20:14:10 <wseltzer> vgb: You should know up-front what you need, ask for the right number of bytes
20:14:33 <jimsch> Why not allow multiple getBytes calls to do the parsing?
20:16:50 <wseltzer> rbarnes: you can create slice as a primitive
20:17:22 <rbarnes> secretAgreement --> octetString
20:17:54 <Zakim> -Karen
20:18:32 <rbarnes> deriveKey( key, { name: "slice", start: 0, end: 16 } )
20:18:44 <rbarnes> deriveByte( key, { name: "slice", start: 16, end: 32 } )
20:19:35 <scottk_> scottk_ has joined #crypto
20:20:12 <hhalpin> non-intuitive if useful examples can be put in examples either in spec or use-cases BTW
20:20:19 <wseltzer> rbarnes: deriveKey is the mechanism we have for deriving key within the boundary
20:21:09 <wseltzer> vgb: don't want to wind up with a Turing-complete parser inside deriveKey
20:22:21 <wseltzer> vgb: we should support all the variants of DH and MQV. static-static, static-ephemeral
20:22:26 <jimsch> deriveKey currently does not take a byte array - how is this going to be done?
20:22:28 <ddahl> wseltzer: so sorry, I have to disconnect
20:22:48 <Zakim> -ddahl
20:23:13 <rbarnes> jimsch: Key object representing a symmetric key is effectively a byte array
20:23:14 <wseltzer> vgb: MQV: my private key, my public key, your public key.
20:23:28 <wseltzer> ... difficult to express all the variants
20:23:37 <wseltzer> ... one or both may add an ephemeral keypair
20:23:41 <jimsch> But you need to get from the bytes returned by deriveBytes to the key object
20:24:22 <wseltzer> ... started by taking multi-party schemes off the table
20:24:46 <wseltzer> rbarnes: are there schemes where there's more than one pub key on the remote side?
20:24:53 <wseltzer> vgb: yes, static and ephemeral
20:25:27 <wseltzer> rbarnes: can you put it into parameters?
20:26:07 <wseltzer> ... which are fixed, which can vary?
20:26:41 <wseltzer> vgb: for DH and MQV, typically at least one keypair for the local party and for the remote party; you may or may not have a second on either side; computations differ
20:27:16 <wseltzer> ... in multi-party schemes it gets more complicated
20:29:37 <wseltzer> rbarnes: can you write the parameters you'd need in the various schemes?
20:29:43 <hhalpin> +1
20:29:45 <wseltzer> vgb: yes, will follow-up to the email
20:29:52 <wseltzer> ... does anyone feel strongly about multi-party?
20:30:02 <jimsch> -1 for multi-party
20:30:09 <wseltzer> rbarnes: I'll reply to that email
20:30:32 <vgb_> vgb_ has joined #crypto
20:30:53 <vgb_> vgb_ has left #crypto
20:30:55 <wseltzer> hhalpin: sounds as though we have a way forward
20:31:09 <wseltzer> ... Mark, any feedback?
20:31:10 <vgb_> vgb_ has joined #crypto
20:32:36 <wseltzer> ... does any of the use cases need this functionality?
20:32:41 <hhalpin> AOB?
20:32:58 <hhalpin> if not, we just need a new version of the proposal.
20:33:18 <hhalpin> Just making sure Mark you'd rather *not* use DH agreement in your use case ;)
20:35:20 <Zakim> - +1.408.458.aacc
20:35:21 <Zakim> -hhalpin
20:35:21 <Zakim> -vgb
20:35:23 <Zakim> -Netflix
20:35:25 <Zakim> - +1.540.809.aaaa
20:35:26 <hhalpin> trackbot, end meeting
20:35:26 <trackbot> Zakim, list attendees
20:35:26 <Zakim> As of this point the attendees have been ddahl, +1.540.809.aaaa, +1.857.928.aabb, +1.408.458.aacc, +1.512.257.aadd, Rich_Schwerdtfeger, Wendy, vgb, jyates, hhalpin, Karen, Netflix
20:35:30 <Zakim> -Wendy
20:35:34 <trackbot> RRSAgent, please draft minutes
20:35:34 <RRSAgent> I have made the request to generate http://www.w3.org/2013/05/13-crypto-minutes.html trackbot
20:35:35 <trackbot> RRSAgent, bye
20:35:35 <RRSAgent> I see no action items
20:35:35 <Zakim> -Rich_Schwerdtfeger