<trackbot> Date: 13 May 2013

<rbarnes> azkim, i am ??P10

<vgb> scribenick: vgb

key lifecycle and key agreement meeting

<hhalpin> anyone want to step forward with a proposal on best way forward?

<hhalpin> it seems key agreement is needed :)

<wseltzer> action-84?

<trackbot> ACTION-84 -- Richard Barnes to vgb and jimsch to discuss key generation/derivation/agreement -- due 2013-05-21 -- OPEN

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

hhalpin: what are we doing here?

<rbarnes> hm, i'm not accounted for in the "on the phone" list

vgb: ACTION 84

<jimsch> I am still not getting a valid pass coe - so irc only

<hhalpin> deriveKey

<hhalpin> flagged unclear it's the best way is way

<rbarnes> also, i've been pretty much offline for the last week, so i'm probably unaware of things that have happened that recently

hhalpin: need to make decision on how to do key agreement

<hhalpin> I'm pretty sure key agreement is *not* in spec

<hhalpin> These seem like basic primitives

<jimsch> That what I was trying.

<hhalpin> wendy?

<hhalpin> David?

<wseltzer> scribenick: wseltzer

hhalpin: Goal, concrete proposal on key agreement to make formal proposal to go into next version of the spec

vgb: Sent an email earlier today
... what we're trying to do: I'd be happy to cover DH and MQV
... finite fields and elliptic curves.
... Start with simple cases.
... Value in having a derivekey method, but given how many use KDF as generic, need derivebytes
... so email made two proposals: derivebytes, and secret agreement

<rbarnes> this may be a dumb idea, but could we just have polymorphism between ArrayBufferView and Key == ABV inside the envelope ?

vgb: take set of key handles, output a key handle

@@: so you mean we'd do keyAgreement, then deriveBytes?

vgb: you don't get to see the key directly, just the derived bytes

<hhalpin> deriveKey and deriveBytes are separate

<hhalpin> +1

vgb: encourage good practice, by not stepping out of the envelope unless necessary

rbarnes: what about case where app wants to derive multiple things from octets from keyAgreement?

vgb: You should know up-front what you need, ask for the right number of bytes

<jimsch> Why not allow multiple getBytes calls to do the parsing?

rbarnes: you can create slice as a primitive

<rbarnes> secretAgreement --> octetString

<rbarnes> deriveKey( key, { name: "slice", start: 0, end: 16 } )

<rbarnes> deriveByte( key, { name: "slice", start: 16, end: 32 } )

<hhalpin> non-intuitive if useful examples can be put in examples either in spec or use-cases BTW

rbarnes: deriveKey is the mechanism we have for deriving key within the boundary

vgb: don't want to wind up with a Turing-complete parser inside deriveKey
... we should support all the variants of DH and MQV. static-static, static-ephemeral

<jimsch> deriveKey currently does not take a byte array - how is this going to be done?

<ddahl> wseltzer: so sorry, I have to disconnect

<rbarnes> jimsch: Key object representing a symmetric key is effectively a byte array

vgb: MQV: my private key, my public key, your public key.
... difficult to express all the variants
... one or both may add an ephemeral keypair

<jimsch> But you need to get from the bytes returned by deriveBytes to the key object

vgb: started by taking multi-party schemes off the table

rbarnes: are there schemes where there's more than one pub key on the remote side?

vgb: yes, static and ephemeral

rbarnes: can you put it into parameters?
... which are fixed, which can vary?

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
... in multi-party schemes it gets more complicated

rbarnes: can you write the parameters you'd need in the various schemes?

<hhalpin> +1

vgb: yes, will follow-up to the email
... does anyone feel strongly about multi-party?

<jimsch> -1 for multi-party

rbarnes: I'll reply to that email

hhalpin: sounds as though we have a way forward
... Mark, any feedback?
... does any of the use cases need this functionality?

<hhalpin> AOB?

<hhalpin> if not, we just need a new version of the proposal.

<hhalpin> Just making sure Mark you'd rather *not* use DH agreement in your use case ;)

<hhalpin> trackbot, end meeting

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: vgb
Found ScribeNick: wseltzer
Inferring Scribes: vgb, wseltzer
Scribes: vgb, wseltzer
ScribeNicks: vgb, wseltzer
Default Present: 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
Present: 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 rbarnes
Found Date: 13 May 2013
Guessing minutes URL: http://www.w3.org/2013/05/13-crypto-minutes.html
People with action items: