19:55:27 <RRSAgent> RRSAgent has joined #crypto
19:55:27 <RRSAgent> logging to http://www.w3.org/2013/04/15-crypto-irc
19:55:29 <trackbot> RRSAgent, make logs public
19:55:31 <trackbot> Zakim, this will be SEC_WebCryp
19:55:31 <Zakim> ok, trackbot; I see SEC_WebCryp()4:00PM scheduled to start in 5 minutes
19:55:32 <trackbot> Meeting: Web Cryptography Working Group Teleconference
19:55:32 <trackbot> Date: 15 April 2013
19:55:41 <wseltzer> Regrets+ Virginie
19:57:32 <jyates> jyates has joined #crypto
19:58:36 <Zakim> SEC_WebCryp()4:00PM has now started
19:58:43 <Zakim> + +1.857.928.aaaa
19:59:46 <Zakim> + +1.650.214.aabb
20:00:02 <ddahl> ddahl has joined #crypto
20:00:31 <jyates> aaaa=jyates
20:00:47 <Zakim> + +1.512.257.aacc
20:00:53 <rsleevi> rsleevi has joined #crypto
20:01:02 <Zakim> +ddahl
20:01:04 <rsleevi> Zakim, who is on the line?
20:01:04 <Zakim> I don't understand your question, rsleevi.
20:01:06 <karen> aacc is Karen
20:01:09 <rsleevi> Zakim, who is on the phone?
20:01:09 <Zakim> On the phone I see +1.857.928.aaaa, +1.650.214.aabb, +1.512.257.aacc, ddahl
20:01:16 <rsleevi> Zakim, aabb is Google
20:01:16 <Zakim> +Google; got it
20:01:19 <rsleevi> Zakim, Google has rsleevi
20:01:19 <Zakim> +rsleevi; got it
20:01:37 <Zakim> +[IPcaller]
20:01:38 <karen> Zakim, aacc is Karen
20:01:39 <Zakim> +Karen; got it
20:01:51 <jyates> Zakim, aaaa is jyates
20:01:51 <Zakim> +jyates; got it
20:02:07 <Zakim> +??P10
20:02:17 <wseltzer> zakim, ??p10 is I
20:02:17 <Zakim> +wseltzer; got it
20:02:22 <nvdbleek> nvdbleek has joined #crypto
20:02:38 <nvdbleek> zakim, code?
20:02:38 <Zakim> the conference code is 27978 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), nvdbleek
20:03:03 <Zakim> +??P11
20:03:19 <nvdbleek> zakim, I am ??P11
20:03:19 <Zakim> +nvdbleek; got it
20:03:38 <nvdbleek> zakim, who is here?
20:03:38 <Zakim> On the phone I see jyates, Google, Karen, ddahl, [IPcaller], wseltzer, nvdbleek
20:03:40 <Zakim> Google has rsleevi
20:03:40 <Zakim> On IRC I see nvdbleek, rsleevi, ddahl, jyates, RRSAgent, sangrae, hhalpin, Zakim, karen, timeless, slightlyoff, wseltzer, trackbot
20:04:22 <arunranga> arunranga has joined #crypto
20:04:37 <Zakim> +[IPcaller.a]
20:04:46 <hhalpin> Zakim, IPcaller.a is hhalpin
20:04:46 <Zakim> +hhalpin; got it
20:04:54 <hhalpin> chair: hhalpin
20:05:00 <hhalpin> Zakim, pick a scribe
20:05:00 <Zakim> Not knowing who is chairing or who scribed recently, I propose ddahl
20:05:11 <hhalpin> scribe: ddahl
20:05:28 <hhalpin>  http://www.w3.org/2013/04/01-crypto-minutes.html
20:05:34 <hhalpin> PROPOSAL:  http://www.w3.org/2013/04/01-crypto-minutes.html are the correct minutes
20:05:36 <Zakim> + +1.415.294.aadd
20:05:39 <hhalpin> RESOLVED:  http://www.w3.org/2013/04/01-crypto-minutes.html are the correct minutes
20:05:48 <arunranga> Zakim, aadd is arunranga
20:05:48 <Zakim> +arunranga; got it
20:05:56 <hhalpin> topic: Closing issues
20:05:56 <rsleevi> ISSUE-7?
20:05:56 <trackbot> ISSUE-7 -- Deciding if we integrate a high level API in our deliverable -- open
20:05:56 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/7
20:05:58 <hhalpin> ISSUE-7
20:05:58 <trackbot> ISSUE-7 -- Deciding if we integrate a high level API in our deliverable -- open
20:05:58 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/7
20:05:59 <ddahl> hhalpin: mainly dealing in housekeeping today
20:06:08 <ddahl> hhalpin: issue 7 is first
20:06:14 <rsleevi> PROPOSAL: Close ISSUE-7
20:06:20 <arunranga> +1
20:06:22 <ddahl> +1
20:06:22 <hhalpin> +1
20:06:23 <rsleevi> +1
20:06:37 <markw> markw has joined #crypto
20:06:50 <hhalpin> RESOLVED: http://www.w3.org/2012/webcrypto/track/issues/7 is CLOSED due to ddahl's document, but the document may not end up being Rec-track
20:07:06 <hhalpin> ISSUE-17
20:07:06 <trackbot> ISSUE-17 -- Define the scope and API for custom key attributes -- open
20:07:06 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/17
20:07:22 <Zakim> + +1.408.540.aaee
20:07:33 <markw> Zakim, aaee is me
20:07:33 <Zakim> +markw; got it
20:07:34 <ddahl> hhalpin: issue 17 was non-contreversial as well
20:07:46 <hhalpin> PROPOSAL: http://www.w3.org/2012/webcrypto/track/issues/17 is closed and the answer is "there iwll not be aan API for custom key attributes
20:07:49 <rsleevi> +1
20:07:52 <hhalpin> +1
20:07:53 <ddahl> +1
20:08:14 <markw> Zakim, markw is Netflix
20:08:14 <Zakim> +Netflix; got it
20:08:22 <hhalpin>  RESOLVED: http://www.w3.org/2012/webcrypto/track/issues/17is closed and the answer is there will not be an API for custom key attributes
20:08:32 <markw> Zakim, Netflix has markw, skelly
20:08:32 <Zakim> +markw, skelly; got it
20:08:47 <ddahl> hhalpin: next is issue 22
20:08:53 <hhalpin> http://www.w3.org/2012/webcrypto/track/issues/22
20:08:57 <ddahl> ... cloneable discussion
20:08:58 <hhalpin> I do not aymeric
20:08:59 <rsleevi> ISSUE-22?
20:08:59 <trackbot> ISSUE-22 -- Should CryptoOperations be clonable -- open
20:08:59 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/22
20:09:10 <hhalpin> does anyone else want clonability?
20:09:19 <ddahl> hhalpin: amyeric is the only one who wanted clonaeability
20:10:10 <ddahl> rsleevi: not stong feelings either way, aymeric's use cases and explanations were not ideal, not going to cry if it goes away, even though there may actualy be solid usecases
20:10:33 <ddahl> hhalpin: we could keep it open and if no uses cases come up, we close it
20:10:48 <ddahl> rsleevi: there are use cases, but, do we need thins in v. 1.0?
20:10:57 <hhalpin> Zakim, who's making noise?
20:11:05 <arunranga> Can we list the strong use cases for .clone that are better than Aymeric's scary ones?
20:11:10 <Zakim> hhalpin, listening for 10 seconds I heard sound from the following: [IPcaller] (25%), hhalpin (10%), arunranga (74%)
20:11:15 <arunranga> Zakim, mute me
20:11:15 <Zakim> arunranga should now be muted
20:11:49 <hhalpin> PROPOSAL: Close ISSUE-22 until we have a more tighter use-case and then add a new issue for that use-case
20:11:53 <rsleevi> +1
20:11:55 <hhalpin> +1
20:11:57 <ddahl> +1
20:11:58 <sangrae> +1
20:12:06 <nvdbleek> +1
20:12:07 <hhalpin> RESOLVED: Closed ISSUE-22 until we have a more tighter use-case and then add a new issue for that use-case
20:12:28 <hhalpin> http://www.w3.org/2012/webcrypto/track/issues/32
20:12:30 <Zakim> + +82.22.14.0.aaff
20:12:32 <hhalpin> that's in SysApps now
20:12:44 <ddahl> hhalpin: issue 32, secure element, moved to sysaps WG
20:13:13 <mountie> mountie has joined #crypto
20:13:17 <rsleevi> q+
20:13:21 <ddahl> hhalpin: anyone here in sysaps? establishing a connection with them might make some sense
20:13:41 <hhalpin> ack rsleevi
20:13:47 <karen> q+
20:13:50 <hhalpin> anyone else from sysapps here?
20:13:53 <ddahl> hhalpin: sysaps WG should be notified that we are not doing anything with secure element
20:14:17 <ddahl> rsleevi: gemalto has proposed the secure element API
20:14:36 <ddahl> rsleevi: not aware of any formal agreements on implementing it
20:14:36 <hhalpin> http://www.w3.org/2012/sysapps/
20:15:07 <ddahl> hhalpin: this is a scoping issue and we are agreeing to not handle smartcard/seciure element apis
20:15:16 <hhalpin> ack karen
20:15:20 <ddahl> hhalpin: proposes that we close issue 32
20:15:56 <MIchael> MIchael has joined #CRYPTO
20:15:59 <hhalpin> So we want to interoperate with any future work (likely via Key Discovery work) in terms of SmartCard and SecureElements, but we are not writing our own APIs for these areas
20:16:15 <ddahl> karen: question: assume the sec element api made its way into sysapps...
20:16:35 <rsleevi> q+
20:16:35 <ddahl> if we want to convert or map the sysapp key to the web crypto API?
20:16:38 <nvdbleek> sounds good to me, but keeping a door open for smart card access through a discovery API might be an option in my opinion
20:16:41 <ddahl> ... how is that done
20:16:47 <Zakim> + +1.512.257.aagg
20:16:53 <hhalpin> PROPOSAL: ISSUE-32 closed insofar as Secure Elements is now in SysApps, and interoperability with any future API will be done via interoperability with Key Discovery Draft.
20:16:56 <hhalpin> ack rsleevi
20:16:57 <Scott_Kelly> Scott_Kelly has joined #crypto
20:17:03 <ddahl> karen: sooner or later we will need to deal with interoperability
20:17:25 <mountie> Zakim, list attendees
20:17:25 <Zakim> As of this point the attendees have been +1.857.928.aaaa, +1.650.214.aabb, +1.512.257.aacc, ddahl, rsleevi, [IPcaller], Karen, jyates, wseltzer, nvdbleek, hhalpin, +1.415.294.aadd,
20:17:28 <Zakim> ... arunranga, +1.408.540.aaee, markw, skelly, +82.22.14.0.aaff, +1.512.257.aagg
20:17:59 <mountie> Zakim, aaff is mountie
20:17:59 <Zakim> +mountie; got it
20:18:03 <ddahl> rsleevi: not going to deal with apis not in scope or theoretical implenations
20:18:23 <wseltzer> q?
20:18:29 <ddahl> rsleevi: we recognize that this is not a problem for this WG to take on at this time
20:19:02 <ddahl> karen: we don not want to solve the problem right now, but do WG generally work together with overlapping interests?
20:19:12 <jeffh> jeffh has joined #crypto
20:19:41 <ddahl> hhalpin: sometimes you have atask force between 2 WGs for related work
20:20:26 <sangrae> IPcaller is sangrae. Sangrae Cho from ETRI
20:20:55 <ddahl> ... we might want to clarify that we will handle keys from secure elements via key discovery api at alater time
20:21:37 <rsleevi> q+
20:21:46 <ddahl> hhalpin: within a use case doc we can specify the interop here
20:21:48 <hhalpin> ack rsleevi
20:22:14 <ddahl> rsleevi: the proposal in sysaps by gemalto is not the same as our own use case
20:23:01 <ddahl> rsleevi: there is very clear charter sep. between the issues, but there are 2 different problems here between the WGs
20:23:08 <nvdbleek> you might also have a look at the wiki page I started about certificate discovery https://github.com/InventiveDesigners/webcrypto-key-certificate-discovery-js/wiki/API
20:23:39 <hhalpin> PROPSOAL: ISSUE-32 closed insofar as Secure Elements is now in SysApps, and interoperability with any future API will be done via interoperability with Key Discovery Draft.
20:23:46 <hhalpin> +1
20:23:59 <hhalpin> s/PROPOSOAL/PROPOSAL
20:24:00 <nvdbleek> +1
20:24:16 <mountie> +1
20:24:16 <rsleevi> -1, due to the committment on interoperability for as of yet unspecified APIs
20:24:30 <ddahl> i agree with rsleevi here
20:24:31 <rsleevi> Would prefer the second clause dropped
20:24:45 <sangrae> +1
20:24:55 <hhalpin> PROPOSAL: ISSUE-32 closed insofar as Secure Elements is now in SysApps
20:24:58 <rsleevi> +1
20:25:05 <ddahl> hhalpin: we could say possible future interop
20:25:08 <ddahl> +1
20:25:15 <hhalpin> any objections to simpler terminology?
20:25:45 <hhalpin> RESOLVED: ISSUE-32 closed insofar as Secure Elements is now in SysApps
20:25:48 <rsleevi> @hhalpin - there are lots of other interop issues beyond key discovery (eg: handling of APDUs and crypto operations via smart cards, hence my objection
20:25:50 <ddahl> hhalpin: no objections, discussion next
20:26:16 <hhalpin> section: unwrap and wrapping
20:26:17 <ddahl> hhalpin: unwarp/ wrap and separation of alg and operation params again
20:27:14 <rsleevi> q+
20:27:18 <ddahl> markw: I am suggesting we just rename tsome things and move things around as there has been some confusion in reading the key gen / operation params
20:28:07 <ddahl> markw: we should separate and clarify the dictionaries used in algs and operations
20:28:08 <hhalpin> ack rsleevi
20:28:22 <ddahl> rsleevi: naming is hard
20:28:55 <ddahl> rsleevi: we should simplify things, however, not sure if there is no overlpa at all
20:29:07 <markw> Q=
20:29:12 <markw> q+
20:29:13 <ddahl> rsleevi: you don't want to be able to generate a key that you cannot use
20:29:50 <hhalpin> thus, the relationship to  operation and algorithm parameters
20:30:06 <hhalpin> q?
20:30:08 <hhalpin> ack markw
20:30:31 <ddahl> markw: agree with the comments that this is hard to nail down here
20:30:59 <rsleevi> q+
20:31:16 <ddahl> markw: not sure how the operation params need to be re-specified once the key is already generated
20:31:32 <hhalpin> ack rsleevi?
20:32:15 <ddahl> rsleevi: i am in agreement in the idea of if we move paramters to the key we should not have to specify in operation, but there are edge cases here
20:32:35 <ddahl> ... when we start writing example code the spec vastly changes
20:32:46 <ddahl> ... some hesitation here yest
20:33:23 <ddahl> hhalpin: makes sense to walk through this very carefully in the face to face
20:33:29 <rsleevi> ack rsleevi
20:33:33 <ddahl> .. or not as time may be limited?
20:33:42 <hhalpin> topic: f2f scheduling
20:34:11 <ddahl> rsleevi: i am planning on working through the issues before our f2f
20:34:24 <hhalpin> www.w3.org/2012/webcrypto/wiki/F2F_April2013
20:34:32 <ddahl> rsleevi: [the devil is in the details]
20:34:33 <hhalpin> lunch -> 4:30 PM