16:01:01 <RRSAgent> RRSAgent has joined #crypto
16:01:01 <RRSAgent> logging to http://www.w3.org/2013/04/23-crypto-irc
16:01:03 <trackbot> RRSAgent, make logs public
16:01:03 <Zakim> Zakim has joined #crypto
16:01:05 <trackbot> Zakim, this will be SEC_WebCryp
16:01:05 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
16:01:06 <trackbot> Meeting: Web Cryptography Working Group Teleconference
16:01:06 <trackbot> Date: 23 April 2013
16:01:12 <wseltzer> chair: Virginie
16:02:11 <tlr> tlr has joined #crypto
16:02:41 <MichaelH> MichaelH has joined #CRYPTO
16:03:09 <markw> markw has joined #crypto
16:03:18 <jmackay> jmackay has joined #crypto
16:04:33 <rsleevi> Present: Ryan Sleevi
16:04:38 <jin> jin has joined #crypto
16:04:55 <rsleevi> Zakim, who is here?
16:04:55 <Zakim> sorry, rsleevi, I don't know what conference this is
16:04:56 <Zakim> On IRC I see jin, jmackay, markw, MichaelH, tlr, Zakim, RRSAgent, rsleevi, rbarnes, tobie, slightlyoff, wseltzer, trackbot
16:05:04 <SooHyung> SooHyung has joined #crypto
16:05:09 <karen> karen has joined #crypto
16:05:58 <wseltzer> topic: Introductions
16:05:59 <rsleevi> present+ Ryan Sleevi
16:06:17 <hhalpin> hhalpin has joined #crypto
16:06:26 <rsleevi> present+ Wendy_Seltzer
16:06:57 <wseltzer> present+ Nick_Van_Den_Bleeken
16:07:06 <wseltzer> present+ Sangrae_Cho
16:07:34 <wseltzer> present+ Seung-Hun_Jin
16:07:52 <Jyates> Jyates has joined #Crypto
16:08:00 <wseltzer> present+ Mountie_Lee
16:08:13 <wseltzer> present+ Harry_Halpin
16:08:31 <wseltzer> present+ Karen_O'Donoghue
16:08:44 <wseltzer> present+ Karen_Lu
16:08:45 <tlr> present+ Thomas_Roessler
16:08:56 <sangrae> sangrae has joined #crypto
16:08:56 <wseltzer> present+ Jason_Mackay
16:09:24 <nvdbleek> nvdbleek has joined #crypto
16:09:34 <hhalpin> Anyone in IRC not here physically?
16:10:17 <hhalpin> Zakim, this is crypto
16:10:17 <Zakim> sorry, hhalpin, I do not see a conference named 'crypto' in progress or scheduled at this time
16:10:31 <jin> present+ SooHyung Kim
16:11:01 <rsleevi> Meeting: WebCrypto WG F2F April 23, 2013
16:11:07 <RRSAgent> I have made the request to generate http://www.w3.org/2013/04/23-crypto-minutes.html tlr
16:11:18 <ddahl> ddahl has joined #crypto
16:11:20 <rsleevi> Chair: virginie
16:11:29 <wseltzer> rrsagent, pointer?
16:11:29 <RRSAgent> See http://www.w3.org/2013/04/23-crypto-irc#T16-11-29
16:12:52 <timeless> timeless has joined #crypto
16:12:58 <nvdbleek> scribe: nvdbleek
16:13:22 <nvdbleek> scribe:nick
16:13:22 <drogersuk> drogersuk has joined #crypto
16:13:26 <nvdbleek> scribenick:nvdbleek
16:14:11 <hhalpin> scribe: hhalpin
16:14:11 <ddahl> ddahl has joined #crypto
16:14:19 <hhalpin> Zakim, scribenick hhalpin
16:14:19 <Zakim> I don't understand 'scribenick hhalpin', hhalpin
16:14:23 <hhalpin> scribenick hhalpin
16:15:21 <hhalpin> topic: welcome
16:15:43 <hhalpin> virginie: introduces the agenda
16:15:56 <hhalpin> agenda+ status of all deliverables
16:16:05 <hhalpin> agenda+ Web Crypto API status
16:16:23 <hhalpin> agenda+ key discovery
16:16:30 <hhalpin> agenda+ testing
16:16:38 <hhalpin> agenda+ use-cases
16:16:43 <hhalpin> agenda+ high-level
16:16:45 <rsleevi> Agenda for F2F also at http://www.w3.org/2012/webcrypto/wiki/F2F_April2013
16:17:11 <hhalpin> agenda+ certificates
16:17:13 <wseltzer> q?
16:17:14 <hhalpin> agenda+ bignum
16:17:28 <hhalpin> agenda+ wrapping up
16:18:17 <hhalpin> virginie: AOB?
16:18:39 <hhalpin> virginie: notes twitter map, use #W3CSanJose hashtag http://bluenod.com/map/sotb3
16:19:21 <hhalpin> Zakim, next agendum
16:19:21 <Zakim> agendum 1. "status of all deliverables" taken up [from hhalpin]
16:19:56 <hhalpin> virginie: 45 participants, 12 invited experts
16:20:02 <hhalpin> virginie: real life about 15 people on calls
16:20:44 <hhalpin> virginie: Apple, Inventive Designer, Aymeric Vitte, Karen and Jim as invited expert
16:20:52 <hhalpin> ... deliverables extended by 9 months
16:21:01 <hhalpin> ... web cryptoAPI LC October
16:21:40 <hhalpin> ... Key Discovery API
16:21:44 <hhalpin> ... Use Cases Document
16:21:51 <hhalpin> ... some "maybe" deliverables
16:21:55 <hhalpin> ... high-level API
16:21:59 <hhalpin> ... security framework
16:23:20 <hhalpin> ... notes open ACTIONS and ISSUES are mostly out of date
16:23:32 <hhalpin> ... implementations: Polycrypt.net and now one by Inventive Designer
16:25:31 <rsleevi> TPAC is Nov 11-15
16:25:34 <hhalpin> next f2f 11-15th of Nov in China
16:25:38 <wseltzer> [http://www.w3.org/2013/11/TPAC/]
16:25:54 <selfissued> selfissued has joined #crypto
16:26:46 <hhalpin> notes that rsleevi and jim schaad may be at risk for next f2f
16:28:08 <hhalpin> rsleevi: some open issues that I'm pushing to close them
16:28:43 <mountie> mountie has joined #crypto
16:28:52 <hhalpin> ... dependency on HTML
16:29:18 <hhalpin> ... support of node.js, server based environments
16:29:42 <hhalpin> ... wants time to discuss Futures
16:30:20 <hhalpin> ... event model is the only dependency we have on the DOM
16:30:33 <hhalpin> ... there will still be a dependency on the DOM if we transition to futures
16:30:46 <hhalpin> ... but it does not require mutations etc, so can polyfill
16:31:02 <rbarnes> futures in whatwg spec: http://dom.spec.whatwg.org/#futures
16:31:57 <hhalpin> rsleevi: final decision on defaults and how to handle them
16:32:55 <hhalpin> I volunteer to double-check ACTION and ISSUE list during 10:00 AM coffee break
16:33:19 <rsleevi> DOM Futures: http://dom.spec.whatwg.org/#futures
16:33:34 <rsleevi> Latest ED: https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html
16:33:47 <rsleevi> CryptoOperaiton interface: https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#cryptooperation-interface
16:33:59 <virginie> virginie has joined #crypto
16:34:00 <rsleevi> KeyOperation interface: https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#KeyOperation-interface
16:34:33 <hhalpin> present+ Israel
16:35:19 <hhalpin> rsleevi: one concern in DOM elements is there are things that don't make sense, crypto shoudn't bubble or be cancelled in an async API
16:35:21 <scottk> scottk has joined #crypto
16:35:51 <hhalpin> ... led by script-coord and TAG is a way to look at WebApps APIs and migrating them to Futures
16:36:08 <Susan-home> Susan-home has joined #crypto
16:36:15 <ddahl> Futures are also referred to as "Promises"
16:36:17 <hhalpin> ... already present in JQuery
16:36:27 <hhalpin> ... and many other APIs
16:36:36 <Susan-home> Susan-home has left #crypto
16:36:43 <rsleevi> new CryptoOperation(...).process(SomeData).then(process(some_more_data)).then(process(even_more)).then(finish(...))
16:37:21 <israelh> israelh has joined #Crypto
16:37:22 <slightlyoff> Futures aren't a heavy DOM dependency
16:37:26 <rbarnes> i actually don't think that example works
16:37:33 <slightlyoff> they only need the event loop, which node does provide
16:37:45 <slightlyoff> (sorry, can't join the call)
16:37:48 <rbarnes> as i understand it, then() calls don't chain like that
16:37:52 <slightlyoff> rsleevi:
16:37:57 <slightlyoff> that's some wonky API
16:38:16 <slightlyoff> unless process returns functions
16:38:16 <hhalpin> israel: from the serverside, do we need to implement a whole DOM model
16:38:17 <hhalpin> ... to be crypto compliant
16:38:32 <slightlyoff> israelh: no, only Futures and whatever else is implied
16:38:33 <hhalpin> ... if we are to implement any kind of shimming
16:38:41 <hhalpin> ... bubbling and capturing come into play
16:38:50 <hhalpin> ... if its just async notifications then its not a big deal
16:38:53 <rbarnes> fwiw, here's polycrypt's half-hearted polyfill: http://polycrypt.net/common/pcevent.js
16:39:01 <ddahl> q+
16:39:02 <hhalpin> ... that's Microsoft's main concern
16:39:09 <virginie> q?
16:39:28 <hhalpin> rsleevi: removes bubble-able, cancelable, all you need is event loop
16:39:35 <nvdbleek> q+
16:39:48 <slightlyoff> rbarnes: there's a polyfill for Futures here: https://github.com/slightlyoff/DOMFuture/tree/master/polyfill
16:39:51 <hhalpin> ddahl: we've seen JS move away from DOM and into other place
16:39:53 <slightlyoff> and it runs on Node already
16:40:00 <hhalpin> ... its a huge plus for developers
16:40:17 <slightlyoff> ddahl: we don't need to implicate all of DOM for this...I'm happy to invite annevk here to help clear up the misconceptions
16:40:18 <rbarnes> slightlyoff: duly noted for polycrypt adaptation once ryan changes the spec :)
16:40:25 <hhalpin> ... using Futures, we don't have to switch contexts
16:40:28 <ddahl> q-
16:40:37 <slightlyoff> 'cause I'm hearing only "it says DOM!" on the tin, not a real objection based on inspection of what Futures are
16:40:39 <hhalpin> ack nvdbleek
16:41:06 <slightlyoff> hhalpin: understood.
16:41:19 <hhalpin> nvdbleek: how do you do error handling?
16:41:23 <slightlyoff> hhalpin: which is why I'm trying to dispel potential misconceptions early = )
16:41:46 <markw> q+
16:41:56 <slightlyoff> .then() handers take both success and error callbacks
16:42:06 <tlr> slightlyoff, we can dial into bridge if you want to listen in
16:42:14 <rbarnes> .then(success, failure)
16:42:17 <hhalpin> rsleevi: you just do normal catches with .then(), no dependencies of DOM stuff like observers
16:42:18 <annevk> annevk has joined #crypto
16:42:25 <hhalpin> mwatson: what's the deal with ECMA and Futures?
16:42:37 <slightlyoff> I've asked annevk to joine
16:42:43 <slightlyoff> I'm on TC39
16:42:45 <hhalpin> rsleevi: many of ECMA TC39 people are working on Futures, its can all be implementable in ECMA functions
16:42:51 <nvdbleek> ack, me
16:43:04 <tlr> annevk, slightlyoff -- we're not currently on bridge, but can dial in if you want to listen to discussion
16:43:11 <slightlyoff> and DOM moves faster than TC39, which is why it was decied we'd do it there first and them move it back into the language
16:43:12 <hhalpin> ... it just uses language concepts rather than DOM concepts
16:43:13 <virginie> q?
16:43:19 <ddahl> virginie: we need the phone dialed in
16:43:21 <hhalpin> ... so it will probably come in future ECMAscript
16:43:27 <slightlyoff> tlr: sorry, in another meeting, can't join = (
16:43:29 <israelh> q+
16:43:31 <hhalpin> mwatson: how will migration be?
16:43:31 <annevk> tlr, thanks, but I'll try to follow from here
16:43:35 <hhalpin> rsleevi: it should just work
16:43:42 <slightlyoff> hhalpin: compatible = )
16:43:45 <slightlyoff> hhalpin: if we do it right
16:43:52 <hhalpin> ... by integrating it into language we can ofcourse optimize better
16:43:53 <slightlyoff> hhalpin: subsetting and/or core API compat
16:44:32 <slightlyoff> the best-case scenario is that this happens as a mass import and "Future" becomes a class that ES defines, not DOM
16:44:35 <slightlyoff> which is entirely compatible
16:44:39 <slightlyoff> (so logn as the APIs are)
16:44:47 <slightlyoff> worst case, they diverge somewhat, and ES defines "Promise"
16:44:51 <israelh> q-
16:44:55 <hhalpin> israel: whats the issues with doing DOM in Futures?
16:44:57 <slightlyoff> in that case, DOM re-casts it's class as a subclass of that
16:45:02 <slightlyoff> in which case we still get compat
16:45:17 <slightlyoff> there's nothing really DOM-ish about Futures at this point
16:45:28 <slightlyoff> only that the event loop doesn't exist in JS-the-language yet
16:45:30 <hhalpin> rsleevi: so far, no global scope problems, we haven't had problems there
16:45:33 <slightlyoff> and it does in DOM
16:45:42 <markw> q-
16:45:45 <slightlyoff> and won't until ES7
16:45:49 <slightlyoff> which is a LONG way off
16:45:51 <hhalpin> rsleevi: how to handle progressive events
16:45:59 <hhalpin> ... Futures is a single listener
16:46:07 <hhalpin> ... crypto works well for that
16:46:21 <markw> \me @slightlyoff: thx - makes sense
16:46:25 <hhalpin> ... there is active discussion on progressive notifications, as that doesn't impact our API
16:46:28 <MichaelH> q+
16:46:28 <virginie> q?
16:46:31 <hhalpin> ... as we have the FSM with "progress" and "finish"
16:46:34 <hhalpin> ack MichaelH
16:46:58 <hhalpin> MichaelH: the intention is to make this API work on the serverside?
16:47:10 <hhalpin> rsleevi: current security considerations are non-normative
16:47:22 <hhalpin> ... serverside has a different privacy model
16:47:44 <hhalpin> ... client side, that's why we used structured clone
16:47:51 <hhalpin> ... to avoid privacy issues etc.
16:48:07 <hhalpin> ... in node.js environment, you'll have a trusted domain, you don't have those non-normative concerns
16:48:35 <hhalpin> ... in a hypothetical world, you have a single-server instance with multiple applicaiton containers, you might scope key material to application containers
16:48:46 <hhalpin> ... but none of the normative bits of spec are impacted there
16:50:02 <hhalpin> MichaelH: on client side, we can have certain security checks like same origin, isn't that done in UA?
16:50:20 <annevk> FWIW, futures are completely self-contained.
16:50:26 <mountie> q+
16:50:31 <hhalpin> rsleevi: the checks aren't in the API, the checks on same origin come from structured clone, i.e. IndexedDB
16:50:47 <hhalpin> ... node.js would just support whatever structured clone it tends to use
16:50:54 <hhalpin> ... i.e. a simulation of localStorage
16:50:55 <annevk> We're implementing them in Mozilla and would love APIs to adopt them to give developers a saner experience long term.
16:51:31 <hhalpin> mountie: in certificate side, the UI is impacted, so when we implement on server side, then there are considerations for same origin policies
16:51:35 <slightlyoff> we've also got an engineer lined up on the Chrome side
16:51:50 <hhalpin> ... structured cloneable is not acceptable for the Korean use-case
16:51:59 <annevk> Also, personally, I think if node.js favors a different API from browsers that is okay. But for browsers futures the way forward (the future, harhar).
16:52:09 <annevk> is the way*
16:52:23 <hhalpin> rsleevi: quick response, as regards Key Discovery there's different concerns from a web browser than from outside
16:52:49 <virginie> q?
16:52:59 <hhalpin> ... the security considerations objection from Korea as regards structured clone we should do after lunch
16:53:16 <hhalpin> virginie: what's impact?
16:53:27 <hhalpin> rsleevi: everything is based on event model
16:53:31 <slightlyoff> again, not part of the current discussion, but if anyone has questions about Futures, you can mail me
16:53:36 <hhalpin> ... we still have a normative dependency on DOMSpec, but we don't use event model
16:53:39 <slightlyoff> (slightlyof at chromium dot org)
16:53:42 <israelh> q+
16:53:53 <hhalpin> Zakim, Israel is israelh
16:53:53 <Zakim> sorry, hhalpin, I do not recognize a party named 'Israel'
16:54:12 <selfissued> q+
16:54:20 <hhalpin> ... the idea is that we can get by the objections
16:54:24 <hhalpin> ack israelh
16:54:42 <virginie> q?
16:54:52 <hhalpin> israelh: what is impact on that for us as a browser?
16:55:02 <hhalpin> ... changes in our JS engine, in our browser engine?
16:55:29 <hhalpin> rsleevi: alex russell (slightlyoff) can solve this, so there's a polyfill with events
16:55:34 <MichaelH> q+
16:55:37 <hhalpin> ... we aren't touching ECMAscript here
16:55:54 <ddahl> israelh: this is the mozilla bug for futures: https://bugzilla.mozilla.org/show_bug.cgi?id=856410
16:55:59 <hhalpin> ... just adding javascript function to queue
16:56:11 <virginie> q?
16:56:43 <hhalpin> IsraelH: compliancy seems we don't want polyfills
16:56:47 <rsleevi> http://dom.spec.whatwg.org/#futures
16:57:48 <hhalpin> rsleevi: taking advantage of Javascript functions so we can implement it within JS on the DOM side, so it should be indistguishable?
16:57:51 <virginie> q?
16:57:52 <rbarnes> q+
16:57:56 <rbarnes> retroactively :)
16:58:20 <arun> arun has joined #crypto
16:58:27 <hhalpin> israelh: polyfills have a dependecy on something, if we package that ahead of time, we should not be able to pull it in
16:58:40 <hhalpin> rsleevi: yes, no 3rd-party pull in
16:58:53 <hhalpin> ... futures is so minimal so that it should be done inside API
16:58:58 <hhalpin> q?
16:59:03 <hhalpin> ack selfissued
16:59:06 <rsleevi> repasting slightlyoff's polyfill - https://github.com/slightlyoff/DOMFuture/tree/master/polyfill
16:59:35 <hhalpin> selfissued: your description of Futures sounds like best engineering solution we have
16:59:54 <hhalpin> ... we're not inventing anything, small, self-contained, impact on implementations is minimal, and already existing practice on server-side
17:00:22 <hhalpin> ... israel is the expert here for IE
17:00:30 <hhalpin> MichaelH: the idea is to replace Events with Futures model
17:00:38 <hhalpin> rsleevi: so KeyOperation would just be a future
17:00:59 <slightlyoff> MichaelH: yeh, that's the basic idea
17:01:23 <hhalpin> rsleevi: we'd entirely eliminate event model
17:01:29 <hhalpin> ... we are not doing progress events
17:01:40 <rbarnes> q-
17:01:43 <virginie> q?
17:02:35 <rsleevi> https://github.com/slightlyoff/DOMFuture/blob/master/reworked_APIs/WebCrytpo/after.idl
17:02:46 <hhalpin> hhalpin: we should take an action to have rsleevi update to Futures unless there's an objection
17:03:25 <rsleevi> Coffee break; reconvene in 15 minutes
17:03:55 <annevk> tlr, is futures done being discussed now?
17:04:14 <tlr> in a side meeting
17:08:34 <rbarnes2> rbarnes2 has joined #crypto
17:09:05 <jimsch> jimsch has joined #crypto
17:09:34 <drogersuk> drogersuk has joined #crypto
17:26:23 <Jyates> Jyates has joined #crypto
17:26:51 <kodonog> kodonog has joined #crypto
17:27:03 <rsleevi> hhalpin: We should just walk through the ISSUES and ACTIONS, a lot of have been defacto decided, just need to have a dejure process
17:27:12 <rsleevi> scribenick: rsleevi
17:27:14 <hhalpin> https://www.w3.org/2012/webcrypto/track/issues/open
17:27:33 <vgb> vgb has joined #crypto
17:27:35 <jinsh> jinsh has joined #crypto
17:27:45 <jinsh> exit
17:27:47 <ddahl> +1
17:27:50 <arun> annevk, we did discuss Futures.  The action is that rsleevi will work on a Futures-based WebCrypto draft.
17:27:52 <hhalpin> PROPOSAL: New editors draft should use Futures
17:27:55 <hhalpin> +1
17:27:58 <rsleevi> +1
17:28:01 <arun> +1
17:28:06 <jin> jin has joined #crypto
17:28:09 <nvdbleek> +1
17:28:11 <annevk> arun, coolio
17:28:12 <ddahl> +1
17:28:15 <markw> +1
17:28:17 <virginie> +1
17:28:19 <jin> +!
17:28:22 <jimsch> +1
17:28:26 <jin> +1
17:28:27 <MichaelH> +1
17:28:35 <MichaelH> instead
17:28:46 <hhalpin> RESOLVED: New editors draft should use futures
17:28:48 <israelh> +1 to have Ryan work on a new version of the spec that shows how futures can be integrated
17:28:51 <hhalpin> Zakim, next agendum
17:28:51 <Zakim> agendum 2. "Web Crypto API status" taken up [from hhalpin]
17:29:01 <hhalpin> Zakim, agenda?
17:29:01 <Zakim> I see 8 items remaining on the agenda:
17:29:02 <Zakim> 2. Web Crypto API status [from hhalpin]
17:29:02 <Zakim> 3. key discovery [from hhalpin]
17:29:02 <Zakim> 4. testing [from hhalpin]
17:29:02 <Zakim> 5. use-cases [from hhalpin]
17:29:02 <Zakim> 6. high-level [from hhalpin]
17:29:02 <Zakim> 7. certificates [from hhalpin]
17:29:02 <Zakim> 8. bignum [from hhalpin]
17:29:03 <Zakim> 9. wrapping up [from hhalpin]
17:29:04 <mountie> mountie has joined #crypto
17:29:10 <rsleevi> Topic: Open issues
17:29:21 <rsleevi> https://www.w3.org/2012/webcrypto/track/issues/open
17:29:31 <rsleevi> hhalpin: We're gonna go through the issues list and walk through them very quickly
17:29:38 <rsleevi> ... anyone who objects to closing the issue, make your voice heard
17:30:07 <hhalpin> rsleevi: anyone who objects needs to propose a way to solve
17:30:11 <hhalpin> .. the issue
17:30:17 <rsleevi> ISSUE-5?
17:30:17 <trackbot> ISSUE-5 -- Public vs. private key pairs -- managing the key pair via a single or multiple handles -- open
17:30:17 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/5
17:30:34 <jmackay> jmackay has joined #crypto
17:32:13 <hhalpin> rsleevi: do you get one or two key pairs with asymmetric - current spec treats them separately?
17:33:02 <hhalpin> ... since this API provides no storage, we don't do search for them
17:33:11 <hhalpin> MichaelH: How do you know they are associated?
17:33:34 <hhalpin> rsleevi: your application has to make them store that state
17:33:50 <virginie> q?
17:34:18 <rsleevi> q+
17:35:09 <hhalpin> hhalpin: on a high-level, we could imagine a library keeping track of store
17:35:13 <hhalpin> ack rsleevi
17:35:22 <israelh> q+
17:35:50 <hhalpin> rsleevi: key discovery of certificates assumes some key storage, but the question is do we need low-level coupling?
17:36:12 <nvdbleek> Example of layering it on top of the low level API: https://github.com/InventiveDesigners/webcrypto-key-certificate-discovery-js/wiki/API#x509certificate
17:36:44 <hhalpin> ack israelh
17:37:24 <hhalpin> israelh: by virtue of getting both back at once the issue is solved
17:37:45 <hhalpin> rsleevi: key object is a promise there is key material *somewhere*, but the key material itself doesn't necessarily go into indexedDB
17:37:57 <hhalpin> ... that key material may exist in keyStorage, what is stored is a reference
17:38:11 <hhalpin> karen: keystorage is dependent on UA?
17:38:13 <ddahl> q+
17:38:14 <hhalpin> rsleevi: correct
17:38:39 <hhalpin> ... key object is a promise that key material exists, when you try to use key object then crypto-operation fails if key doesn't exist
17:38:46 <arun> q?
17:38:53 <Jyates> Jyates has joined #crypto
17:39:23 <hhalpin> ddahl: there is storage, the key property allows API behind the scene to get a hold of material, no public
17:39:26 <virginie> q?
17:39:31 <hhalpin> rsleevi: default is non-exportable
17:39:34 <ddahl> q-
17:39:37 <hhalpin> virginie: any objections?
17:39:54 <rsleevi> ISSUE-8?
17:39:54 <trackbot> ISSUE-8 -- Making sure we describe the clean key neutering -- open
17:39:54 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/8
17:40:02 <nvdbleek> issue-8?
17:40:02 <trackbot> ISSUE-8 -- Making sure we describe the clean key neutering -- open
17:40:02 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/8
17:41:07 <hhalpin> PROPOSAL: Close Public vs. private key pairs -- managing the key pair via a single or multiple handles: we generate two key objects and application maintains state
17:41:17 <hhalpin> CLOSED: Public vs. private key pairs -- managing the key pair via a single or multiple handles
17:41:18 <ddahl> +1
17:41:32 <hhalpin> PROPOSAL: CLOSE Making sure we describe the clean key neutering  key neutering
17:41:37 <hhalpin> arun: its not really relevant
17:41:43 <rsleevi> ISSUE-9?
17:41:43 <trackbot> ISSUE-9 -- what will be the mean to integrate in the API the fact that key usage may need user consent ? -- open
17:41:43 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/9
17:42:14 <virginie> q?
17:42:45 <arun> q?
17:42:46 <mountie> q+
17:42:52 <hhalpin> PROPOSAL: CLOSE ISSUE-9: what will be the mean to integrate in the API the fact that key usage may need user consent ?
17:42:53 <virginie> q?
17:42:54 <ddahl> use a french accent when speaking to the chair
17:43:13 <hhalpin> arun: its using same origin, so whats the point?
17:43:27 <rsleevi> q+
17:43:33 <hhalpin> rbarnes: there is postMessage for cross-origin sharing, but we don't want user consent
17:43:37 <hhalpin> ... for every postMessage
17:43:43 <karen> q+
17:44:02 <hhalpin> mountie: user consent seems dangerous, in our historical experience users always click yes
17:44:11 <rsleevi> q?
17:44:18 <rbarnes> q+
17:44:26 <ddahl> users will have no idea what "is it Ok for foo.com to create a keypair for you?" :)
17:44:27 <hhalpin> ack mountie
17:44:51 <rsleevi> ack rsleevi
17:44:56 <hhalpin> rsleevi: no user consent considerations in current API, although maybe in Key Discovery
17:45:00 <arun> q?
17:45:12 <hhalpin> ack karen
17:45:37 <drogersuk> q+
17:45:42 <hhalpin> karen: who owns the key? currently is webapp, or is it user?
17:45:47 <hhalpin> ... if user owns key, then user has to consent
17:45:53 <hhalpin> ... all the keys are owned by the webapp
17:45:55 <hhalpin> q+
17:46:14 <hhalpin> mountie: big issue, who do keys belong to?
17:46:23 <nvdbleek> If we close this issue could we add a comment to the issue, that this issue is about the low level API and *not* about any future key discovery API
17:46:23 <hhalpin> ack rbarnes
17:46:34 <tantek> tantek has joined #crypto
17:46:44 <arun> q+
17:46:44 <MichaelH> q+
17:46:45 <hhalpin> rbarnes: key export is one way to have accountability
17:47:02 <hhalpin> ack drogersuk
17:47:02 <rbarnes> ack rbarnes
17:47:21 <israelh> q+
17:47:23 <hhalpin> drogersuk: is there any kind of holding issue around the security and usability?
17:47:26 <karen> q+
17:47:30 <markw> q+
17:49:41 <hhalpin> ack hhalpin
17:49:59 <hhalpin> hhalpin: thinks that it goes into scope of key discovery
17:50:10 <rbarnes> q?
17:50:12 <hhalpin> drogersuk: we should do a security review of key discovery
17:50:20 <arun> q-
17:50:38 <drogersuk> ...and security review of web crypto api too overall
17:51:27 <hhalpin> MichaelH: What about government exposing API?
17:51:55 <hhalpin> rsleevi: this API will interact with other key discovery mechanisms with pre-existing key material in smart cards, platform storage, etc.
17:52:01 <hhalpin> ... but we are trying to avoid those
17:52:31 <virginie> q?
17:52:56 <hhalpin> MichaelH: What's the point of the API then?
17:53:31 <hhalpin> rsleevi: persona uses keys without using pre-existing keys and uses postMessage to interact with potentially hostile use-cases?
17:54:54 <annevk> annevk has left #crypto
17:55:36 <hhalpin> hhalpin: we are trying to move key import/export into the Key Discovery
17:55:42 <hhalpin> MichaelH: Yet about sign?
17:55:53 <rbarnes> q+
17:55:56 <markw> @hhalpin: why ?
17:56:19 <hhalpin> @markw key discovery is essentially "import", correct?
17:56:31 <hhalpin> I've noted there's no export anywhere.
17:56:44 <rbarnes> hhalpin: i thought there was export in the API
17:56:48 <virginie> q?
17:56:51 <rbarnes> ack rbarnes
17:56:58 <virginie> ack MichaelH
17:57:21 <hhalpin> markw: if someone can build it into polyfill without user-interaction, then why require browser to polyfill?
17:57:31 <hhalpin> ack israelh
17:57:49 <hhalpin> israel: what is expectation for user? for us to ask the user is to break application?
17:57:59 <markw> @hhalpin: in the main draft, import/export refers specifically to passing keying material between JS and UA
17:58:29 <israelh> q-
17:58:29 <ddahl> +1 on no more modal dialogs!
17:58:33 <hhalpin> @markw: I was discussing the pre-existing key material quesiton from MichaelH
17:58:35 <markw> @hhalpin: key discovery is the UA accessing keys that are stored somewhere else (i.e. did not come from the script through import)
17:58:54 <markw> so, key discovery != import
17:59:10 <hhalpin> @markw, then the real question is then should import/export be done anywhere?
17:59:13 <rsleevi> q+
17:59:15 <JonathanJ3> JonathanJ3 has joined #crypto
18:00:07 <hhalpin> karen: there are cases where consent is needed with different kinds of keys
18:00:19 <hhalpin> rbarnes: that is more of an access control issue, we are not defining on what keys can be used for
18:00:34 <markw> @hhalpin: sure, I think several of the use-cases need import or export
18:00:41 <nvdbleek> q+
18:00:42 <arun> q?
18:00:49 <hhalpin> karen: we should make this clear
18:00:52 <hhalpin> ack karen
18:01:09 <hhalpin> markw: do we rely UA for access control, then your totally open to attack
18:01:10 <rsleevi> ack markw
18:01:15 <hhalpin> ... due to polyfill problems
18:01:31 <rsleevi> Zakim, close the queue
18:01:31 <Zakim> ok, rsleevi, the speaker queue is closed
18:02:03 <hhalpin> rsleevi: we should not exist other specs
18:02:08 <rbarnes> well, everything *except* the key isolation is polyfill-able
18:02:17 <rbarnes> but that's not what we're talking about here
18:02:20 <hhalpin> s/reference/exists
18:02:24 <markw> because the main API is polyfillable, any application which relies on UA behaviours (such as user auth) is open to attack by the page being modified to use a polyfil instead of the UA WebCrypto
18:02:28 <hhalpin> ... that may not exist
18:02:38 <tantek> tantek has joined #crypto
18:03:05 <markw> this is exactly why you need key discovery some some applications, because that key is *only* available through the UA and you can then rely on the UA authorization UI
18:03:27 <hhalpin> nvdbleek: we are not preventing access via some special UI
18:03:41 <hhalpin> ... adding extra text that its not allowed to access is not a good idea
18:03:42 <rsleevi> @markw: +1. New specs can add new UI as appropriate - or any other additional access controls
18:04:25 <arun> Ultimately, users are at the mercy of the origins ("domains") they visit.  WebCrypto doesn't alter this.
18:04:36 <virginie> Proposal : close the issue-9, have an action for karen to suggest a sentence explaining that the key belongs on to the webapp, open a action to review the spec in terms of user interaction
18:04:38 <hhalpin> PROPOSAL: CLOSE what will be the mean to integrate in the API the fact that key usage may need user consent ?
18:04:53 <rsleevi> Zakim, open the queue
18:04:53 <Zakim> ok, rsleevi, the speaker queue is open
18:04:53 <rbarnes> +1
18:04:54 <MichaelH> +1
18:04:55 <hhalpin> +1
18:04:55 <rsleevi> +1
18:04:57 <virginie> +1
18:04:58 <nvdbleek> +1
18:04:59 <ddahl> +1
18:04:59 <markw> +1
18:04:59 <arun> +1
18:05:02 <jin> +1
18:05:09 <vgb> +1
18:05:16 <MichaelH> -1
18:05:24 <jimsch> +0
18:05:35 <hhalpin> The proposal is that no new text is necessary to add to the specification about user interaction
18:05:38 <israelh> +1
18:05:42 <mountie> +1
18:06:07 <nvdbleek> But not completely sure we need extra text, we need to be carful not to block use cases that are solved by the current spec
18:06:22 <hhalpin> virginie: we re-visit tomorrow after MichaelH talks to rsleevi
18:07:06 <virginie> q?
18:07:09 <hhalpin> jimschaad: not quite happy to close it, maybe the security and legal implications are not clean
18:07:14 <virginie> ack rsleevi
18:07:25 <virginie> ack nvdbleek
18:07:30 <nvdbleek> ack, me
18:07:35 <ddahl> q+
18:07:48 <hhalpin> drogersuk: should we have 'userdenied"?
18:07:53 <hhalpin> rsleevi: but that leaks information?
18:08:29 <hhalpin> ... namely, it reveals key exists
18:08:37 <hhalpin> drogersuk: signing invoices, contracts on the web
18:08:46 <hhalpin> q+
18:08:49 <karen> q+
18:09:15 <hhalpin> nvdbleek: smart cards have popup for PIN
18:09:24 <hhalpin> ... that would inside smartcard, not web app
18:10:02 <virginie> q?
18:10:50 <hhalpin> ddahl: session pop-up like geolocation, that's only what mozilla implents
18:10:52 <rsleevi> ack ddahl
18:11:18 <ddahl> hypothetically, it is the only kind of thing I can see Mozilla implementing, but I doubt it
18:11:24 <drogersuk> drogersuk has joined #crypto
18:11:40 <drogersuk> q+
18:11:41 <rsleevi> hhalpin: The proposal is that we say nothing in the current API
18:11:55 <rsleevi> ... that when other APIs exist that may need to specify additional properties, such as smart cards, they specify it then
18:12:13 <rsleevi> ... the only place that you can see there being maybe concerns is related to key import/export
18:12:27 <mountie> q+
18:12:29 <rsleevi> ... perhaps revisit this tomorrow morning, but that we try to close this out before the end of the F2F
18:12:32 <rsleevi> Zakim, close the queue
18:12:32 <Zakim> ok, rsleevi, the speaker queue is closed
18:12:33 <hhalpin> ack hhalpin
18:12:37 <rsleevi> ack mountie
18:12:56 <rsleevi> ack karen
18:13:10 <rsleevi> karen: earlier there was the comment about leaking information.
18:13:24 <rsleevi> ... is there a way to not tell the application the failure is because the key doesn't exist or because it was denied
18:13:31 <virginie> q?
18:13:52 <rsleevi> rsleevi: That was in the old spec, when we dealt with key discovery. That you don't have distinct error codes
18:14:06 <hhalpin> drogersuk: my idea is to look at errors
18:14:11 <hhalpin> ... geolocation didn't work
18:14:19 <hhalpin> ... after 5 clicks it just remembers what you've said forever
18:15:11 <hhalpin> virginie: lets revisit this issue with this action tomorrow
18:15:22 <rsleevi> ISSUE-10?
18:15:22 <trackbot> ISSUE-10 -- Making sure our API is usable with pure js environement -- open
18:15:22 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/10
18:15:54 <rsleevi> ISSUE-12?
18:15:54 <trackbot> ISSUE-12 -- Should the API distinguish between algorithm and operation parameters? -- open
18:15:54 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/12
18:16:13 <rsleevi> ISSUE-14?
18:16:13 <trackbot> ISSUE-14 -- Representation of raw key material -- open
18:16:13 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/14
18:16:48 <hhalpin> JWK for import/export
18:17:18 <hhalpin> PROPOSAL: CLOSE Representation of raw key material as we are dealing with JWK for import/export
18:17:25 <rsleevi> ISSUE-19?
18:17:25 <trackbot> ISSUE-19 -- Does it make sense to have authorized-origin and specific-origin keys -- open
18:17:25 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/19
18:18:30 <hhalpin> CLOSE ISSUE-19: Does it make sense to have authorized-origin and specific-origin keys - dealt with by same origin
18:18:33 <rsleevi> RESOLVED: Close ISSUE-14
18:18:38 <rsleevi> RESOLVED: Close ISSUE-19
18:18:41 <rsleevi> ISSUE-21?
18:18:41 <trackbot> ISSUE-21 -- Requiring Content-Security-Policy -- open
18:18:41 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/21
18:18:44 <mountie> +q
18:18:46 <mountie> q+
18:19:22 <rsleevi> Zakim, open the queue
18:19:22 <Zakim> ok, rsleevi, the speaker queue is open
18:19:23 <rsleevi> q+
18:19:30 <rsleevi> ack drogersuk
18:20:05 <hhalpin> mountie: we don't cover CSP in its entirety
18:20:13 <hhalpin> ddahl: An informative action
18:20:19 <hhalpin> ... to add a little note
18:20:37 <hhalpin> mountie: I found the WebAppSec approach is different than our approach in Korea
18:20:44 <hhalpin> ... but some things are not touched, some are not overlapped
18:20:52 <hhalpin> ... so we need to add a comment to WebAppSec
18:20:56 <hhalpin> ... or we handle it differently
18:22:08 <mountie> q+
18:22:24 <rsleevi> ack rsleevi
18:22:52 <rsleevi> rsleevi: The proposal was to only expose the API to web pages that had opted into CSP
18:23:27 <rsleevi> mountie: Perhaps for Web Crypto, we need more policies
18:23:56 <rsleevi> virginie: Can you take an action to write a proposal
18:23:57 <rsleevi> q+
18:23:58 <rsleevi> ack mountie
18:24:50 <rsleevi> ack rsleevi
18:25:07 <ddahl> I think we want a *note* that cautions users of this API to know about and use a Content Sec Policy that makes sense for them. there are a million ways to use CSP and mandating a specific set of rules is impossible
18:25:13 <ddahl> q+
18:25:26 <rbarnes> web sites that use this spec SHOUDL use CSP
18:25:28 <rsleevi> hhalpin: Options are normative note - requiring CSP - informative note - telling people CSP exists and recommending it - or saying nothing
18:25:32 <virginie> q?
18:25:48 <rsleevi> ddahl: Trying to mandate the use of CSP is a non-starter, completely, because there's a million ways to use CSP and a million ways to enact a policy
18:26:04 <rsleevi> ddahl: Perhaps a lot of this stems from my ignorance last year when I raised this (laughter)
18:26:22 <rsleevi> ddahl: Propose we put this as a SHOULD - developers PLEASE read this
18:26:43 <rsleevi> ACTION: sleevi to write informative text recommending CSP
18:26:43 <trackbot> Created ACTION-78 - Write informative text recommending CSP [on Ryan Sleevi - due 2013-04-30].
18:27:17 <rsleevi> PROPOSAL: Close ISSUE-21 with sleevi to address it via ACTION-78
18:27:21 <rsleevi> RESOLVED: Close ISSUE-21
18:27:23 <rsleevi> ISSUE-23?
18:27:23 <trackbot> ISSUE-23 -- Should CryptoOperations and/or Keys support Transferrable semantics? -- open
18:27:23 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/23
18:29:40 <hhalpin> operations need to transferable rather than cloneable to maintain internal state
18:29:50 <rsleevi> PROPOSAL: Close ISSUE-23 with no action to the spec
18:29:53 <rsleevi> RESOLVED: ISSUE-23 will be closed
18:30:04 <rsleevi> ISSUE-24?
18:30:04 <trackbot> ISSUE-24 -- Defining a Synchronous API -- open
18:30:04 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/24
18:32:12 <rsleevi> markw: There was a point where we wanted to do synchronous operations for window.close, but we're willing to let that slip
18:32:25 <rsleevi> markw: There needs to be an ability to perform async operations on shutdown, but that's not an issue for this WG
18:32:34 <rsleevi> PROPOSAL: Close ISSUE-24 with no changes
18:32:35 <markw> now we would like to do asyncronous operations in onclose instead ;-)
18:32:38 <rsleevi> RESOLVED: Closed ISSUE-24
18:33:20 <rsleevi> ISSUE-25
18:33:20 <trackbot> ISSUE-25 -- How do we provision Global Unique ID for pre-provisionned symetric keys -- open
18:33:20 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/25
18:33:47 <rsleevi> PROPOSAL: Close ISSUE-25
18:33:52 <rsleevi> RESOLVED: Close ISSUE-25
18:33:55 <rsleevi> ISSUE-26?
18:33:55 <trackbot> ISSUE-26 -- Should key generation be allowed to specify multi-origin shared access -- open
18:33:55 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/26
18:34:09 <rsleevi> PROPOSAL: Close ISSUE-26
18:35:06 <rsleevi> mountie: Is this related to certificates or key gen?
18:35:28 <rsleevi> rsleevi: Because the spec has nothing to say about key storage or discovery, theres no way to give a Key object to another origin, short of postMessage
18:35:37 <rsleevi> mountie: generating the keys in one origin and using the keys in another origin
18:35:38 <rsleevi> q+
18:35:46 <ddahl> q-
18:36:05 <rsleevi> mountie: Maybe clonable can be a technical solution, but because of the political/technical restrictions
18:36:14 <arun> q?
18:36:27 <rsleevi> vgb: Why is clonable not suitable?
18:36:40 <rsleevi> mountie: Key generation from Origin A and Origin B wants to use the key to initiate the signature
18:36:46 <rsleevi> mountie: Then Origin B needs to access the keys from Origin A
18:37:05 <rsleevi> ... that means only origin A can initiate the transactions
18:37:28 <hhalpin> rsleevi: if we see how native APIs solve this problem
18:37:36 <hhalpin> ... in every national scheme, there's a smartcard middleware
18:37:45 <hhalpin> ... there's some autohorization
18:38:19 <hhalpin> ... in Origin A and Origin B generates a message and Origin A has a message it wants to be signed
18:38:34 <hhalpin> ... user trusts Origin A and Origin B is an arbitrary application
18:38:41 <hhalpin> ... you don't want to just give your key to Origin B.
18:39:01 <karen> q+
18:39:19 <hhalpin> ... you can use existing Web technologies (i.e. postMessage), Origin B can deal with use-cases and Origin A can do inbound checks
18:41:12 <hhalpin> mountie: postMessage we need a response before continuing other process
18:41:13 <hhalpin> ... we don't want to lose our JS logic
18:41:25 <hhalpin> q+
18:41:30 <arun> q+
18:41:32 <arun> q?
18:41:33 <rsleevi> q-
18:42:16 <vgb> q+
18:42:37 <rsleevi> karen: What rsleevi described is certainly a workable solution - origin A always performs the signing as a service
18:42:45 <arun> mountie, rsleevi was referring to using code of this kind: http://html5demos.com/postmessage2
18:42:51 <rsleevi> ... but there are privacy concerns with this, in that origin A can always see what's being signed
18:43:13 <virginie> q?
18:43:14 <arun> mountie, this would be on a "per operation" basis; thus, "operated upon" payloads might be exchanged between domains.
18:43:25 <rsleevi> ... theres another scenario with pre-existing keys where the user owns the key
18:43:47 <rsleevi> ... where the user should authorize that Origin B should use the key
18:43:50 <rsleevi> rbarnes: ... Isn't that a different issue? Back to discovering pre-existing keys?
18:44:00 <rsleevi> rsleevi: Right. That's not cross-origin sharing
18:44:14 <rsleevi> q?
18:44:19 <rsleevi> ack karen
18:44:35 <rsleevi> virginie: Is your proposal that you want to keep the issue open? Are you objecting to closing the issue?
18:44:42 <rsleevi> ISSUE-26?
18:44:42 <trackbot> ISSUE-26 -- Should key generation be allowed to specify multi-origin shared access -- closed
18:44:42 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/26
18:44:53 <virginie> q?
18:45:00 <rsleevi> israelh: How is that scenario what you described different from what rsleevi described
18:45:54 <rsleevi> karen: It's more related to key discovery
18:46:13 <rsleevi> israelh: We should separate the two - the key discovery part and the origin sharing
18:46:53 <MichaelH> q+
18:47:03 <hhalpin> ack hhalpin
18:47:05 <rsleevi> hhalpin: There are two elements. Do we close out ISSUE-26 because everything we've done is dealt with same-origin-policy
18:47:12 <hhalpin> My proposal is to close ISSUE-26
18:47:22 <hhalpin> but then add new actions to have Karen and Mountie work through the use-cases tomorrow
18:47:59 <virginie> q?
18:48:01 <hhalpin> ack arun
18:48:11 <hhalpin> arun: Let's work through these use-cases, I think we can obviate them
18:48:35 <rsleevi> ack vgb
18:48:38 <vgb> q-
18:48:40 <hhalpin> my suggestion is to have actions on mountie and karen to write these use-cases down and work thorugh them in person tomorrow
18:48:42 <hhalpin> q?
18:48:45 <hhalpin> ack MichaelH
18:48:46 <drogersuk_> drogersuk_ has joined #crypto
18:48:50 <JonathanJ3> JonathanJ3 has joined #crypto
18:49:52 <virginie> q?
18:50:02 <hhalpin> MichaelH: Can WebApp A generate a key and then pass that key object to WebApp B - both those scenarios work, via postMessage/CORs
18:50:11 <hhalpin> rsleevi: yes, that's how it works
18:50:17 <hhalpin> vgb: cloning is cloning the pointer
18:51:43 <rsleevi> PROPOSAL: CLOSE Issue-26
18:51:48 <rsleevi> RESOLVED: CLOSE ISSUE-26
18:51:59 <rsleevi> ACTION: karen to write up use case for the pre-provisioned key discovery use case
18:51:59 <trackbot> 'karen' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., klu, kodonog).
18:52:09 <vgb> q+
18:52:10 <rsleevi> ACTION: mountie to write up a use case for the origin sharing
18:52:10 <trackbot> Created ACTION-79 - Write up a use case for the origin sharing [on Mountie Lee - due 2013-04-30].
18:52:19 <rsleevi> ACTION: klu to write up use case for the pre-provisioned key discovery use case
18:52:19 <trackbot> Created ACTION-80 - Write up use case for the pre-provisioned key discovery use case [on Karen Lu - due 2013-04-30].
18:52:27 <rsleevi> ISSUE-28?
18:52:27 <trackbot> ISSUE-28 -- Short-names for algorithms -- open
18:52:27 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/28
18:53:18 <selfissued> q+
18:53:29 <virginie> q?
18:53:34 <markw> q+
18:54:08 <rsleevi> ddahl: It seems like something a high-level shim could do
18:54:31 <rsleevi> vgb: I agree with Richard's point that it can help to usability
18:54:46 <virginie> q?
18:54:51 <rsleevi> vgb: We don't have to take (Dictionary or DOMString) - we can just make it take it in the name
18:55:11 <rsleevi> richard: the question is whether it should be in the API or the implementation, seems generally useful to put in the API
18:55:44 <rsleevi> selfissued: I don't have a strong position on whether or not we should have a short name form in the API, but to the extent that we do, I do think they should overlap with the JOSE JWA spec
18:55:53 <rsleevi> ... It would be silly to use a different string should this working group decide to do that
18:55:59 <rsleevi> ... but not taking a position on whether we should
18:56:01 <rsleevi> ack vgb
18:56:03 <rsleevi> ack selfissued
18:56:25 <rsleevi> markw: In a discussion with Ryan the other day, I realized this relates to the discussion of separation for operation and algorithm parameters
18:56:41 <rsleevi> ... My question is do you want short names for algorithms, or do you also want short names for operations
18:56:43 <virginie> q?
18:56:58 <rsleevi> vgb: Algorithm seems like it makes more sense
18:57:28 <rsleevi> markw: So the example of HMAC where you have the hash algorithm - should the hash algorithm be a property of operation or of the algorithm
18:57:45 <selfissued> q+
18:57:52 <rsleevi> markw: My proposal would be we have a clean separation of algorithm/operation parameters, and we only have short names for algorithm parameters
18:57:54 <rsleevi> ack markw
18:58:04 <rsleevi> It relates to ISSUE-12
18:58:10 <rsleevi> (which we postponed)
18:58:48 <rsleevi> rsleevi: I certainly agree to the point that ISSUE-12 and ISSUE-28 are closely coupled
18:59:32 <rsleevi> selfissued: The JOSE JWA algorithms are intended to be the complete specification of the cryptographic functions
18:59:49 <rsleevi> jimsch: That's not a completely true statement - the IV is not included in the name
18:59:58 <rsleevi> vgb: The MGF is more an algorithm parameter, not an operation parameter
19:00:44 <rsleevi> selfissued: the IV is an input
19:00:48 <rsleevi> jimsch: But so is the MGF
19:00:58 <rsleevi> selfissued: The choice of MGF is an input that specifies a cryptographic function, and the JWAs attempt to specify all the cryptographic functions
19:01:58 <rsleevi> markw: We already have examples of properties that are not intrinsic properties of keys. We have to make a (hopefully) non-arbitrary decision about what to bind to properties of keys
19:02:01 <rsleevi> q+
19:02:04 <rsleevi> ack selfissued
19:02:11 <rsleevi> markw: I would err on the side of binding stuff to the key
19:02:49 <rsleevi> jimsch: Would you argue that the hash (for RSA keys) is such a property
19:02:59 <rsleevi> rbarnes, vgb: Yes
19:03:09 <rsleevi> vgb: I would argue you want to early bind parameters
19:03:14 <rsleevi> q?
19:04:08 <rsleevi> q-
19:05:19 <rsleevi> ISSUE-29?
19:05:19 <trackbot> ISSUE-29 -- Handling of block encryption modes and padding -- open
19:05:19 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/29
19:05:55 <rsleevi> PROPOSAL: Close 29
19:06:44 <vgb> +1
19:06:53 <rsleevi> RESOLVED: Treat ISSUE-29 as part of ISSUE-12
19:06:56 <rsleevi> ISSUE-30?
19:06:56 <trackbot> ISSUE-30 -- How does the application know where the key is stored ? -- closed
19:06:56 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/30
19:07:09 <rsleevi> ISSUE-32?
19:07:09 <trackbot> ISSUE-32 -- Section 5.2 in API draft should mention use of secure element in the context of key security -- open
19:07:09 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/32
19:08:10 <virginie> q?
19:08:23 <MichaelH> q+
19:08:46 <rsleevi> ACTION: sleevi to describe we're not storing key material itself in IDB
19:08:46 <trackbot> Created ACTION-81 - Describe we're not storing key material itself in IDB [on Ryan Sleevi - due 2013-04-30].
19:09:26 <rsleevi> q?
19:09:51 <rsleevi> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#security
19:10:12 <virginie> ack MichaelH
19:10:40 <rsleevi> q?
19:11:10 <rsleevi> q+
19:13:26 <virginie> q?
19:13:30 <hhalpin> hhalpin: I've noted lots of confusion around structured clone that the minimum requirement (plain text) and maximum security requirements.
19:13:30 <rsleevi> q-
19:13:35 <hhalpin> ... perhaps an informative note would be useful?
19:14:56 <rsleevi> PROPOSAL: Close ISSUE-32
19:15:00 <rsleevi> RESOLVED: Close ISSUE-32
19:15:06 <hhalpin> ACTION: vgb to write sentence about how structured clone relates to different types of key storage and that that key storage may have high-security implications (not in our spec!)
19:15:06 <trackbot> Created ACTION-82 - Write sentence about how structured clone relates to different types of key storage and that that key storage may have high-security implications (not in our spec!) [on Vijay Bharadwaj - due 2013-04-30].
19:17:03 <rbarnes> so, would it be considered bad form to open issues during this meeting?
19:17:21 <rbarnes> there are a couple of things that were raised on the list that i don't think are reflected in the tracker
19:17:21 <rsleevi> rbarnes: Only if we can't resolve them before lunch
19:27:37 <SooHyung> SooHyung has joined #crypto
19:53:51 <jmackay> jmackay has joined #crypto
20:05:27 <markw_> markw_ has joined #crypto
20:05:35 <mountie> mountie has joined #crypto
20:07:10 <hhalpin> hhalpin has joined #crypto
20:07:27 <jmackay> jmackay has joined #crypto
20:07:39 <SooHyung> SooHyung has joined #crypto
20:08:19 <Jyates> Jyates has joined #crypto
20:08:21 <virginie> Diner location and time : 19:30 @ Scott's Seafood 185 Park Avenue San Jose, CA 95113 (408) 971-1700 scottsseafoodsj.com‎
20:10:07 <wseltzer> rrsagent, make minutes
20:10:07 <RRSAgent> I have made the request to generate http://www.w3.org/2013/04/23-crypto-minutes.html wseltzer
20:10:20 <rsleevi> scribenick: nvdbleek
20:10:35 <rsleevi> Topic: Outstanding Issues
20:11:05 <hhalpin> https://www.w3.org/2012/webcrypto/track/issues/open
20:12:43 <arun> arun has joined #crypto
20:13:14 <nvdbleek> selfissued: Can you summarise issue 29
20:13:36 <wseltzer> Issue-12?
20:13:36 <trackbot> ISSUE-12 -- Should the API distinguish between algorithm and operation parameters? -- open
20:13:36 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/12
20:13:50 <wseltzer> s/issue 29/issue 12/
20:14:03 <hhalpin>  I've generally seen "raised" used when your getting mailing list comments and trying to figure out if they are genuine problems or not.
20:14:06 <jin> jin has joined #crypto
20:14:14 <nvdbleek> ???: You shouldn't mix algorithms for the same key
20:14:35 <jimsch> q+
20:14:52 <rsleevi> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#rsa-oaep
20:14:58 <wseltzer> s/???/rsleevi/
20:15:09 <vgb> vgb has joined #crypto
20:15:52 <nvdbleek> rsleevi: how do you decide what goes were key algorithm or parameters
20:16:01 <nvdbleek> rsleevi: There is a proposal
20:16:01 <rbarnes> q+
20:16:39 <wseltzer> ack jimsch
20:16:43 <selfissued> q+
20:16:44 <karen> karen has joined #crypto
20:16:54 <nvdbleek> jimsch: How much of the parameters are encoded in the underlying key?
20:17:11 <israelh> israelh has joined #Crypto
20:17:27 <drogersuk> drogersuk has joined #crypto
20:17:46 <sangrae> sangrae has joined #crypto
20:17:48 <nvdbleek> rsleevi: In most underlying APIs they don't store this specfic information, they don't prevent mixing algorithms
20:18:03 <nvdbleek> rbarnes: The UA should track this extra information
20:18:23 <nvdbleek> ... besides tracking where the key lives
20:18:43 <wseltzer> ack next
20:19:09 <vgb> q+
20:19:11 <nvdbleek> rbarnes: The difference is things that are fixed for the live time of the key apposed to things that vary per operation (can be changed)
20:20:09 <nvdbleek> ... I it could result in simplification
20:20:43 <nvdbleek> ... it removes all duplication
20:21:00 <wseltzer> ack next
20:21:14 <nvdbleek> selfissued: I had reason to read some cryptographic specs
20:21:35 <nvdbleek> ... ??? spec doesn't specify an encryption function
20:21:40 <kodonog> kodonog has joined #crypto
20:21:42 <rsleevi> q+
20:21:46 <rsleevi> s/???/selfissued/
20:22:11 <nvdbleek> ... The HMAC spec is in-depended from the algorithm
20:22:49 <rbarnes> virginie: what's on the agenda for >15:00 ?
20:22:50 <nvdbleek> ... split-up by bound to key and data
20:23:18 <nvdbleek> ... bake AES in GCM , but not IV
20:23:31 <virginie> q?
20:23:31 <rsleevi> q?
20:23:34 <rbarnes> virginie: i can scribe for that
20:23:37 <rsleevi> ack next
20:23:54 <nvdbleek> vgb: I'm in favour of decomposition
20:24:27 <nvdbleek> vgb: it makes it clear to naive implementers
20:25:30 <nvdbleek> ... operation parameters must be changed per operation, the others won't change that often
20:25:34 <markw_> ... it makes it clear to *any* implementors ;-)
20:25:48 <virginie> q?
20:26:18 <markw_> s/... it makes/It makes/
20:26:55 <nvdbleek> rsleevi: the counter argument of not being able to change this is that you have to know everything upfront
20:27:19 <rsleevi> q?
20:27:22 <rsleevi> ack rsleevi
20:27:40 <nvdbleek> vgb: It depends on the use-cases
20:29:00 <nvdbleek> vgb: not being able to change this will make it easier for users as it guides them what they should be able to do securely
20:30:23 <nvdbleek> rsleevi: we need to have a good definition to decide what goes were, otherwise we are going to have an inconsistent API
20:31:07 <nvdbleek> ???: We could go by instinct for now, and then see what rules applies
20:31:31 <rsleevi> s/???/rbarnes/
20:31:34 <nvdbleek> rsleevi: Mark has documented everything
20:31:54 <rsleevi> ACTION: vgb and rbarnes to work through proposal for splitting algorithm and operation parameters, and then retrofit a definition
20:31:55 <trackbot> Created ACTION-83 - And rbarnes to work through proposal for splitting algorithm and operation parameters, and then retrofit a definition [on Vijay Bharadwaj - due 2013-04-30].
20:33:00 <nvdbleek> ACTION-83 due in 3 weeks
20:33:00 <trackbot> Set ACTION-83 And rbarnes to work through proposal for splitting algorithm and operation parameters, and then retrofit a definition due date to 3 weeks.
20:33:29 <nvdbleek> virginie: We keep the action open
20:33:40 <wseltzer> ISSUE-29?
20:33:40 <trackbot> ISSUE-29 -- Handling of block encryption modes and padding -- open
20:33:40 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/29
20:33:40 <rsleevi> ISSUE-29?
20:33:40 <trackbot> ISSUE-29 -- Handling of block encryption modes and padding -- open
20:33:41 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/29
20:33:52 <nvdbleek> TOPIC: Handling of block encryption modes and padding
20:33:56 <Jyates> Jyates has joined #crypto
20:34:28 <virginie> s/keep the action open/keep the issue open/
20:35:21 <virginie> q?
20:36:18 <rsleevi> scribenick: rsleevi
20:36:22 <nvdbleek> rsleevi: prupose to close issue 29
20:36:25 <rsleevi> PROPOSAL: ISSUE-29 to be closed with no action
20:37:15 <rbarnes> the main reason i brought up padding was that the test vectors i was using for PolyCrypt *didn't* use PKCS7
20:38:09 <rsleevi> ISSUE-39?
20:38:09 <trackbot> ISSUE-39 -- Add abort() to the KeyOperation interface -- open
20:38:09 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/39
20:38:16 <nvdbleek> TOPIC:Add abort() to the KeyOperation interface
20:38:37 <nvdbleek> rsleevi: The keyOperation will become a Future
20:39:06 <nvdbleek> rsleevi: In most API's you can't abort key generation
20:40:21 <virginie> q?
20:40:26 <rsleevi> michaelh: Question about generating a key and then exiting the browser
20:40:28 <vgb> vgb has joined #crypto
20:40:29 <nvdbleek> ... If you are using something that isn't specified in this spec, which requires user interaction, you may want an abort
20:41:11 <mountie> q+
20:41:21 <nvdbleek> ???: What happens when you create a key in an onAbort
20:41:31 <rsleevi> s/???/michaelh/
20:41:49 <rsleevi> vgb: From the Windows side, it depends on what you were doing
20:41:59 <rsleevi> ... If you were using a software provider, it would just unload the DLL
20:42:10 <rsleevi> ... if you were using a smart card, it would reset the card. What that does is up to the card os
20:42:11 <nvdbleek> ????: It varies on the type of key/device
20:42:22 <rsleevi> ... If you were using a network provider, it might reset the network connection
20:42:34 <rsleevi> ... it depends on what you were doing and whether or not cleanup would happen
20:42:40 <mountie> q-
20:42:44 <rsleevi> israelh: It really depends on where in the pipeline we're cancelling the call
20:42:59 <rsleevi> ... if we're cancelling while the task is still pending, before we've hit the native code, we can just not run it
20:43:01 <nvdbleek> ???: It depends on were the cncelation happens before are after the native API call
20:43:07 <rsleevi> ... if we're in native code, it depends... we're not gonna return a JS object
20:43:12 <rsleevi> s/???/israelh/
20:43:45 <nvdbleek> rsleevi: That is why abort is tricky
20:44:54 <nvdbleek> ???: If you switch to the future, it is just never calling setvalue, you only my save CPU power
20:45:23 <nvdbleek> rsleevi: You won't be able to save CPU in all cases
20:45:24 <rsleevi> s/???/jmackay
20:45:43 <rsleevi> PROPOSAL: Close ISSUE-39?
20:45:53 <nvdbleek> virginie: It may be acceptable to remove this issue from scope
20:46:11 <nvdbleek> ???: Who raised this issue
20:46:29 <nvdbleek> virginie: It is ????
20:46:43 <wseltzer>  s/is ????/is Wan-Teh/
20:47:47 <nvdbleek> ?????: Will the CryptoOperation still have an abort
20:48:01 <nvdbleek> rsleevi: I think so
20:49:07 <rsleevi> s/???/vgb/
20:49:13 <nvdbleek> rsleevi: in the CryptoOperation will have multiple calls to the native API, so there might be a change to stop calling the native API
20:49:23 <rsleevi> vgb: KeyOperation is atomic, cryptoOperation is not
20:49:23 <nvdbleek> s/change/chance/
20:49:30 <rsleevi> RESOLVED: ISSUE-39 to be closed with no action
20:49:53 <rsleevi> ISSUE-36?
20:49:53 <trackbot> ISSUE-36 -- Semantics for key generation versus key derivation -- open
20:49:53 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/36
20:49:55 <rsleevi> ISSUE-43?
20:49:55 <trackbot> ISSUE-43 -- Separate method for key agreement -- open
20:49:55 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/43
20:50:24 <nvdbleek> TOPIC: Semantics for key generation versus key derivation AND Separate method for key agreement
20:51:46 <rsleevi> q?
20:51:48 <nvdbleek> ???: Recap: tension between derivations and protocol specific IPSec
20:52:33 <rsleevi> s/???/vgb/
20:52:54 <rsleevi> vgb: There was a question of whether we could use generateKey with keys as generation params to yield Key objects
20:52:59 <rsleevi> vgb: and key derivation to yield byte streams
20:53:10 <rsleevi> rbarnes: method names are cheap. It seems there are some conceptual differences
20:53:12 <nvdbleek> ????: generate key has no input, derive does have input
20:53:20 <rsleevi> s/???/rbarnes/
20:53:37 <rsleevi> vgb: A key derivation function doesn't necessarily give you a DES key with all of the parity bits
20:53:58 <rsleevi> vgb: Theres an argument where if I want to do that (where I start with a seed and do something), maybe there should be some easy way to do that
20:54:08 <rsleevi> jimsch: Well, typically you derive keys for a specific algorithm
20:54:21 <virginie> q?
20:54:24 <rsleevi> vgb: Well, if you're doing that, you'd typically derive some random bytes and use that for some input to generate a key
20:54:47 <rsleevi> vgb: generateKey just takes "here's the target algorithm", deriveKey typically takes a "here's a source algorithm to derive bytes, but doesn't tell you how to use those bytes"
20:54:58 <rsleevi> vgb: There's a third type though, that takes both a source and a target algorithm
20:55:03 <nvdbleek> vgb: you only provide the algorithm for generate key, in derive key you also have a source algorithm
20:55:11 <nvdbleek> virginie: What is the state in the spec
20:55:33 <virginie> q?
20:55:35 <rsleevi> rbarnes: To be radical and blue sky about it, you could have an algorithm "here's a source of random bytes, derive me some keys"
20:55:52 <rsleevi> ... and conceptually, if you're drawing serially off a KDF stream, maybe you can do more interesting things
20:56:02 <rsleevi> vgb: The challenges are like with IKEv2 where you're generating 4 keys
20:56:26 <rsleevi> rbarnes: I was more talking about a stream object that you can read serially from
20:57:25 <nvdbleek> vgb: The question is does derive key give out a byte array or a key object
20:57:40 <rsleevi> rsleevi: Where we ended up is that it outputs Key objects, which you could then export
20:58:12 <rsleevi> jimsch: The real problem is sometimes I want to generate a key, sometimes I want to generate a blob
20:58:13 <nvdbleek> rsleevi: Currently it returns a Key object because it was better then a byte[]
20:58:30 <rsleevi> vgb: The example is algorithms that generate a key and an IV, which take an output and splits it into a key and an IV
20:58:50 <rsleevi> jimsch: And then you have interesting ones where you generate a key and a secret, then take that secret and derive a key and a secret, and continue chaining
20:59:06 <nvdbleek> vgb: Doesn't OAUTH generate multiple keys
20:59:06 <rsleevi> vgb: Doesn't oauth generate multiple keys off the same Z value?
20:59:35 <rsleevi> rbarnes: I don't know what the JWE specs coming out today say, but the currently published ones have a separate symmetric and mac key
21:00:10 <nvdbleek> rsleevi: You still need 2 keys
21:00:37 <drogersuk> drogersuk has joined #crypto
21:00:56 <nvdbleek> virginie: How do we going to progress those issues?
21:01:06 <rsleevi> jimsch: One question - which way do you think is the more common case
21:01:07 <nvdbleek> ???: What is the most common case
21:01:15 <rsleevi> s/???/jimsch/
21:01:27 <rsleevi> jimsch: Could you generate a Key blob, export it, then split the bytes, then import it back as keys
21:01:38 <rsleevi> vgb: I think Key and IV is a very common use case
21:02:12 <rsleevi> jimsch: The question is which is more common. Does it make more sense to always just export bytes and then just reimport
21:02:32 <rsleevi> vgb: My gut feel when reading algorithm specifications is they assume the KDF is some sort of PRF where you split stuff up and import it
21:02:59 <rsleevi> rbarnes: One of the issues is you don't specify how many octets of the KDF you want
21:03:14 <rsleevi> virginie: I don't see us solving or progressing on that issue
21:03:30 <rsleevi> ... One suggestion is to have a dedicated call to explore the scenario and perhaps draft a solution
21:03:40 <nvdbleek> virginie: We could have a dedicated call
21:04:06 <rsleevi> ... Proposal is on our alternate weeks dedicate 1 hour for an ad-hoc call to discuss this issue and come to a proposal
21:05:17 <virginie> q?
21:05:52 <jmackay> jmackay has joined #crypto
21:06:04 <nvdbleek> rsleevi: What is the deliverable of those calls? Do we say the key derivation is a feature at risk
21:06:05 <rsleevi> ACTION: vgb, rbarnes, jimsch to discuss key generation/derivation/agreement
21:06:05 <trackbot> Error finding 'vgb,'. You can review and register nicknames at <http://www.w3.org/2012/webcrypto/track/users>.
21:06:59 <nvdbleek> rsleevi: We have to agree on a time frame for the solution
21:07:16 <nvdbleek> virginie: On the 6yh of May we have an extra call
21:07:24 <rsleevi> ACTION: rbarnes vgb and jimsch to discuss key generation/derivation/agreement
21:07:24 <trackbot> Created ACTION-84 - Vgb and jimsch to discuss key generation/derivation/agreement [on Richard Barnes - due 2013-04-30].
21:07:37 <nvdbleek> s/6yh/6th/
21:08:32 <nvdbleek> virginie: The call will be at 20UTC on 6th May
21:08:49 <nvdbleek> virginie: on the 13th we will decide how to progress
21:09:02 <nvdbleek> virginie: issue stays open
21:10:05 <nvdbleek> rsleevi: The issues that we could discuss before the break are all discussed
21:10:47 <nvdbleek> TOPIC: Require creation of random IVs by default for CBC, CFB, GCM
21:11:37 <nvdbleek> ???: Some of the symmetric cryptographic it is sufficient that you generate a random IV every time
21:11:59 <virginie> ISSUE-44?
21:11:59 <trackbot> ISSUE-44 -- Require creation of random IVs by default for CBC, CFB, GCM -- open
21:11:59 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/44
21:12:06 <nvdbleek> ...: This isn't obvious for the common web developer
21:12:24 <rsleevi> s/???/rbarnes/
21:12:30 <rsleevi> q+
21:12:40 <nvdbleek> ...: If it is omitted the UA could generate one
21:12:41 <virginie> s/???/rbarnes/
21:12:57 <nvdbleek> ...: This would be more secure
21:13:10 <vgb> vgb has joined #crypto
21:13:15 <vgb> q+
21:13:22 <rbarnes> q+
21:13:41 <hhalpin> q+
21:13:46 <nvdbleek> rsleevi: I see pro's and con's we need to see for what we want defaults
21:14:06 <nvdbleek> rsleevi: In some cases the IV should be protected
21:14:21 <jimsch> q+
21:14:27 <rsleevi> ack rsleevi
21:14:28 <rsleevi> ack next
21:14:30 <nvdbleek> ...: So generating the IV might be more dangerous
21:14:57 <nvdbleek> ???: Some people set the IV to 0 even if they know that it is dangerous
21:15:06 <rsleevi> s/???/vgb/
21:15:10 <rsleevi> q+
21:15:39 <nvdbleek> ...: We might be better of with a special value or a helper function to generate the IV
21:15:49 <jmackay> jmackay has joined #crypto
21:16:27 <nvdbleek> ...: e.g.: iv:auto
21:16:33 <rsleevi> q?
21:16:46 <rsleevi> ack next
21:17:24 <Jyates> Jyates has joined #crypto
21:17:40 <virginie> q?
21:17:40 <nvdbleek> rbarnes: most of the time you want auto
21:17:51 <rsleevi> rbarnes: There's an element of developer ergonomics where it's just hostile to make users specify
21:18:14 <rsleevi> ack next
21:18:25 <hhalpin> ack hhalpin
21:19:18 <nvdbleek> rbarnes: there is been a study, developers regardless of what they now use what is available, so it should be very simple
21:19:26 <rsleevi> s/rbarnes/hhalpin/
21:19:44 <nvdbleek> ...: an IV helper function makes sense
21:19:54 <tobie> tobie has joined #crypto
21:20:05 <rsleevi> ack next
21:20:08 <nvdbleek> q?
21:20:22 <nvdbleek> rsleevi: protecting the IV you have to ???
21:20:28 <rsleevi> jimsch: Protection of IV, you should only use an AEAD function
21:20:31 <rsleevi> s/rsleevi/jimsch/
21:20:54 <rsleevi> jimsch: There will have to be additional things returned from output
21:20:58 <nvdbleek> ...: There are already other things that we need to return for encrypt operations
21:21:13 <rsleevi> vgb: If I hear you correctly, you're arguing to let the caller omit the IV and return the IV
21:21:24 <rsleevi> jimsch: I don't really care if you use auto or omit - but basically you return it
21:21:25 <rsleevi> ack next
21:21:27 <nvdbleek> vgb: You are proposing to let the caller omit the IV, and return the IV by the operation
21:22:08 <nvdbleek> rsleevi: developers need to protect the IV
21:22:40 <virginie> q?
21:23:04 <nvdbleek> ...: We could return a dictionary
21:24:36 <nvdbleek> selfissued: you could use the API to implement authenticated
21:25:01 <nvdbleek> ...: So the API should return the parameters
21:26:17 <nvdbleek> rsleevi: The safest bet is to add defaults later, if we now add incorrect defaults now we can't fix it later
21:26:39 <nvdbleek> ...: if we add defaults we need to be sure that it are good defaults
21:28:01 <rsleevi> ACTION: rbarnes and vgb to propose a means for auto-generating IVs in 3 weeks
21:28:01 <trackbot> Created ACTION-85 - And vgb to propose a means for auto-generating IVs in 3 weeks [on Richard Barnes - due 2013-04-30].
21:28:05 <nvdbleek> ACTION: richard to make a proposal for an explicit auto generation token for IV
21:28:05 <trackbot> Created ACTION-86 - Make a proposal for an explicit auto generation token for IV [on Richard Barnes - due 2013-04-30].
21:29:01 <nvdbleek> ACTION-85 due in 3 weeks
21:29:01 <trackbot> Set ACTION-85 And vgb to propose a means for auto-generating IVs in 3 weeks due date to 3 weeks.
21:29:28 <nvdbleek> ACTION-85 due in 4 weeks
21:29:28 <trackbot> Set ACTION-85 And vgb to propose a means for auto-generating IVs in 3 weeks due date to 4 weeks.
21:47:12 <jmackay> jmackay has joined #crypto
21:49:26 <mountie> mountie has joined #crypto
21:50:39 <Jyates> Jyates has joined #crypto
21:58:46 <vgb> vgb has joined #crypto
22:00:34 <hhalpin> q+
22:00:46 <Jyates> Jyates has joined #crypto
22:02:14 <jmackay> jmackay has joined #crypto
22:03:16 <nvdbleek> TOPIC: Ask for a formal review of WebApps and HTML
22:03:18 <RRSAgent> I have made the request to generate http://www.w3.org/2013/04/23-crypto-minutes.html rsleevi
22:04:02 <hhalpin> https://www.w3.org/2012/webcrypto/track/actions/74
22:04:09 <nvdbleek> hhalpin: Is the API stable enough?
22:04:09 <rsleevi> ACTION-74?
22:04:09 <trackbot> ACTION-74 -- Harry Halpin to contact PING over privacy -- due 2013-01-28 -- OPEN
22:04:09 <trackbot> http://www.w3.org/2012/webcrypto/track/actions/74
22:05:08 <nvdbleek> rsleevi: We don't have any privacy concerns anymore, everything we can do now can be done in plain javascript
22:05:25 <rbarnes> yep
22:05:27 <nvdbleek> ???: This isn't completely thru
22:05:43 <rbarnes> hhalpin: do we want a security review?  boneh and others have expressed interest
22:05:47 <drogersuk> q+
22:05:53 <nvdbleek> rsleevi: Do we need a security review?
22:05:58 <rbarnes> rsleevi: if you want security review, you don't want cryptgraphers
22:06:21 <rbarnes> hhalpin: also have an action to ask other WGs for review
22:06:28 <virginie> q?
22:06:36 <rbarnes> rsleevi: propose that we address that after next public WD
22:06:37 <hhalpin> ack hhalpin
22:06:41 <drogersuk> q-
22:07:00 <rbarnes> … have intentionally avoided filling in a lot of details while things get worked out
22:07:00 <drogersuk> q+
22:07:10 <rbarnes> … next public WD should have these holes filled in
22:07:28 <rsleevi> q?
22:07:39 <rsleevi> ack next
22:07:44 <nvdbleek> rsleevi: I intentionally didn't fill in the wholes in the spec, because I didn't want to constantly want to change it
22:07:53 <rbarnes> drogersuk: agree that cryptographers != security review
22:08:33 <rbarnes> … when we had the joint meeting with webappsec at TPAC, we agreed that there was a dependency on the web security model
22:08:52 <rbarnes> … there was an action from that that I took to work on documenting the web security model
22:09:18 <rbarnes> … working on kicking off that work with brad hill, adam barth
22:09:34 <nvdbleek> virginie: There are 2 problems:
22:09:45 <nvdbleek> .... : 1) review of the spec
22:10:21 <nvdbleek> ... Would it be possible to have next public WD by the end of May
22:10:45 <nvdbleek> rsleevi: I can have something ready that the group can look at, and decide
22:11:07 <nvdbleek> virginie: Would that be something that is ready for review
22:11:14 <nvdbleek> rsleevi: I think so
22:11:44 <nvdbleek> virginie: 2) Documenting the  Web Security Model
22:14:31 <rbarnes> nvdbleek: i can, but it looked like you were doing it
22:14:35 <rbarnes> i'll start back up
22:14:45 <rbarnes> virginie: ready for LC in october or so?
22:15:09 <rbarnes> hhalpin: ideally if we publish in june, want to go to LC in september / october
22:15:28 <rbarnes> … so if most of our issues are closed by june, close that out by october, then one more round of review and it's over
22:15:54 <rbarnes> rsleevi: the more important gating factor is going to be implementation experience
22:16:02 <virginie> q?
22:16:07 <rbarnes> drogersuk: what about a test suite?
22:16:11 <rbarnes> hhalpin: that's for tomorrow
22:16:46 <rbarnes> virginie: that was for ACTION-74, keeping that open because we're not ready for reviews yet
22:16:53 <rbarnes> … other actions we can close
22:16:53 <rbarnes> ?
22:17:19 <rbarnes> hhalpin: most of the other actions are use case related
22:18:00 <rbarnes> rsleevi: any that we can close out because they're stale?  lots of over-due ones
22:19:04 <rbarnes> hhalpin: building value proposition, higher level API, ...
22:19:15 <rbarnes> … tlr added something about public communications
22:19:32 <rbarnes> … add SEED, keeping that open
22:20:26 <rbarnes> drogersuk: some considerations about jurisdictions where you can't do crypto stuff
22:20:37 <rsleevi> ACTION-67?
22:20:37 <trackbot> ACTION-67 -- Virginie GALINDO to legal aspects with respect to national directives -- due 2012-12-19 -- OPEN
22:20:37 <trackbot> http://www.w3.org/2012/webcrypto/track/actions/67
22:20:54 <rbarnes> … considering export control laws, etc.
22:21:08 <rbarnes> rsleevi: we have no mandatory to implement algorithms...
22:21:30 <rbarnes> … if people are using chrome in iran, that's something the chrome team needs to deal with.  ssl stacks already deal with these issues
22:21:41 <rbarnes> … nothing here for the spec to address; implementors will
22:22:31 <rbarnes> drogersuk: maybe put in a notice, ...
22:22:38 <rbarnes> rbarnes: but what would the notice say?
22:23:00 <rbarnes> drogersuk: more about what new entrants, what they need to consider
22:23:16 <rbarnes> vgb: this is also very dependent on how the UA implements this
22:23:24 <rbarnes> … could build a browser on CNG, not have any crypto in the browser
22:23:53 <rbarnes> … nothing really generic you can say in the spec
22:24:07 <rbarnes> virginie: closing the action with no text?
22:24:47 <rbarnes> drogersuk: has jose discussed this?
22:24:55 <rbarnes> jimsch: nope!
22:25:30 <rbarnes> hhalpin: so, keeping "Add SEED", couple of others, everything else is from today
22:25:39 <rbarnes> … think our action list is pretty well cleaned out
22:25:56 <ddahl> hhalpin:
22:26:03 <ddahl> https://www.w3.org/2012/webcrypto/track/issues/pendingreview
22:26:09 <rbarnes> ddahl: two pending review issues
22:26:10 <rsleevi> ISSUE-2?
22:26:10 <trackbot> ISSUE-2 -- How to address pre-provisioned keys and managing ACLs -- pending review
22:26:10 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/2
22:26:12 <rsleevi> ISSUE-3?
22:26:12 <trackbot> ISSUE-3 -- Decide whether algorithm discovery is necessary -- pending review
22:26:12 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/3
22:26:29 <rbarnes> <unanimous acclamation>: close them!
22:26:38 <rbarnes> q+
22:27:15 <rbarnes> rbarnes: as a developer, how do i figure out if the algorithm i want is there?
22:27:21 <rbarnes> … try it, and if it fails, it fails?
22:27:28 <rsleevi> ISSUE-38?
22:27:28 <trackbot> ISSUE-38 -- Key initialization and "finalization" -- postponed
22:27:28 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/38
22:27:37 <rbarnes> rsleevi: yes
22:27:59 <rbarnes> vgb: is issue 38 really postponed, or should it be closed?
22:28:25 <rbarnes> rsleevi: the idea would be something around key escrow, but the use case was really complicated, and there was not that much support
22:28:27 <rbarnes> ack rbarnes
22:28:40 <rsleevi> ISSUE-2?
22:28:40 <trackbot> ISSUE-2 -- How to address pre-provisioned keys and managing ACLs -- pending review
22:28:40 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/2
22:28:40 <rbarnes> PROPOSAL: Close ISSUE-2
22:29:31 <virginie> q?
22:30:02 <rbarnes> karen: just to clarify for the main spec, there's no issues with pre-provisioned keys, but it is an issue for the WG at some point?
22:31:06 <rbarnes> rsleevi: different topic than base spec, would need consensus to adopt
22:31:26 <rbarnes> karen: so we close this issue for the main spec, but the issue is still around...
22:31:39 <rbarnes> rsleevi: if there's not a spec to attach the issue to, you close the issue
22:31:57 <rbarnes> karen: if we have a use case, it could be re-opened
22:32:26 <rbarnes> hhalpin: this particular issue is poorly phrased.  better to close this, write a new use cases, lead to a new issue
22:33:34 <rbarnes> rsleevi: also a question of whether the use cases document is for the current API, whether the existence of a use case binds the WG to do something about it
22:34:10 <rbarnes> virginie: use case document is living while spec is in development, clean it out as the spec matures
22:34:49 <rbarnes> rsleevi: we have the ED of the use cases, you're saying when we go to WD, we remove the irrelevant use cases?
22:35:39 <rbarnes> israel: it's a little confusing to take things out of the use cases document
22:35:39 <hhalpin> q+
22:35:55 <rbarnes> karen: or else you have separate use cases documents
22:36:14 <rbarnes> israel: exactly, v1 vs v2
22:36:30 <rbarnes> hhalpin: as a start, mark use cases by version
22:36:46 <rbarnes> rsleevi: or, have one document plus a wiki
22:37:05 <Jyates> Jyates has joined #crypto
22:37:50 <rbarnes> hhalpin: wiki has lower visibility, so people might miss it and bring things to the WG
22:39:03 <rbarnes> rsleevi: nobody is proposing adding major functionality at this point ...
22:39:24 <rbarnes> virginie: so we have one use cases document which is aligned with the spec, then other use cases can go on the wiki or in a second document
22:39:35 <rbarnes> … so karen, you are welcome to propose a use case within that framewrok
22:39:55 <rbarnes> karen: two scenarios: asymmetric key and secret key
22:40:43 <rbarnes> … (1) dr. smith has a key pair on her badge in the hospital, wants to sign a prescription, use the key to authenticate to e-prescription website
22:41:48 <rbarnes> … (2) developer signs up for AWS, gets a secret key used for signing API requests
22:42:09 <virginie> q?
22:42:29 <rbarnes> … key producer and consumer are different
22:42:47 <rbarnes> rsleevi: you've mentioned these before, they need to be written down; might be ways to do them in the existing API
22:43:03 <rbarnes> … should close this action because it's broadly written and unrelated to what you're saying
22:43:23 <rbarnes> RESOLVED: Close ISSUE-2
22:43:48 <rsleevi> ISSUE-3?
22:43:48 <trackbot> ISSUE-3 -- Decide whether algorithm discovery is necessary -- pending review
22:43:48 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/3
22:44:08 <rbarnes> q+
22:44:13 <rsleevi> q+
22:44:18 <rsleevi> ack next
22:44:43 <rsleevi> q-
22:44:43 <rbarnes> hhalpin: related to registry question?
22:45:05 <rbarnes> vgb: no
22:45:20 <rbarnes> rbarnes: seems like it could be useful; reason not to?
22:45:37 <rbarnes> rsleevi: yes, lots.  fingerprinting, complexity of expressing constraints, etc.
22:46:10 <rbarnes> vgb: gets even complicated, because different keys have different capabilities as well
22:47:10 <rbarnes> … CNG has an API for discovery, nobody uses it and nobody has expressed a desire to use it
22:47:29 <rbarnes> PROPOSAL: Close ISSUE-3
22:47:45 <rbarnes> RESOLVED: Close ISSUE-3 with no action
22:47:48 <rsleevi> ACTION-54?
22:47:48 <trackbot> ACTION-54 -- Harry Halpin to blog post on w3.org about how the API fits into the larger Web platform -- due 2012-10-01 -- PENDINGREVIEW
22:47:48 <trackbot> http://www.w3.org/2012/webcrypto/track/actions/54
22:48:03 <rbarnes> ISSUE-38?
22:48:03 <trackbot> ISSUE-38 -- Key initialization and "finalization" -- postponed
22:48:03 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/38
22:48:04 <rsleevi> ISSUE-38?
22:48:04 <trackbot> ISSUE-38 -- Key initialization and "finalization" -- postponed
22:48:04 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/38
22:48:32 <rbarnes> virginie: we discussed this and i forgot the outcome
22:48:36 <rbarnes> rsleevi: close with no action
22:48:49 <rbarnes> PROPOSED: Close ISSUE-38 with no action
22:48:56 <rbarnes> RESOLVED: Close ISSUE-38 with no action
22:49:08 <rbarnes> q?
22:49:11 <rbarnes> ack rbarnes
22:49:17 <rbarnes> ISSUE-34?
22:49:17 <trackbot> ISSUE-34 -- Representation of certificates -- postponed
22:49:17 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/34
22:49:34 <rbarnes> virginie: still working on ISSUE-34, so we'll keep it as postponed
22:49:39 <rbarnes> ISSUE-15?
22:49:39 <trackbot> ISSUE-15 -- Discovering certificates associated with (private) keys -- postponed
22:49:39 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/15
22:49:45 <sangrae> sangrae has joined #crypto
22:49:52 <hhalpin__> hhalpin__ has joined #crypto
22:50:00 <rbarnes> virginie: some redundancy with ISSUE-34
22:50:14 <rbarnes> rsleevi: if you don't have a representation for certs, how do you discover them
22:50:31 <rbarnes> vgb: there's two dimensions -- using certs to locate keys, and vice versa
22:50:40 <karen> karen has joined #crypto
22:51:00 <rbarnes> virginie: postponed means that it's not a priority, ok to keep it that way?  <no objection>
22:51:19 <rbarnes> … on ACTION-54 ...
22:51:47 <rbarnes> hhalpin: need to respond to some of the criticism, will do it when we release a public draft
22:52:01 <rbarnes> rsleevi: propose we publish a WD, then see what criticism we get
22:52:41 <rbarnes> hhalpin: we're still going to have critics that say "you shouldn't do this on the web", and "this is too complicated"
22:53:09 <rbarnes> virginie: close for now, re-open when we have some feedback to address?
22:53:18 <rbarnes> RESOLVED: Close ACTION-54
23:11:17 <jmackay> jmackay has joined #crypto
23:15:33 <RRSAgent> I have made the request to generate http://www.w3.org/2013/04/23-crypto-minutes.html rsleevi
23:16:41 <rsleevi> scribenick: rbarnes
23:27:07 <drogersuk> drogersuk has joined #crypto
23:27:55 <Jyates> Jyates has joined #crypto
23:29:26 <rsleevi> scribenick: drogersuk
23:29:50 <rsleevi> Topic: Microsoft Streams & Overloads Proposal
23:30:05 <drogersuk> Israel Hilerio presenting on array buffers
23:30:26 <drogersuk> when using streams it gets a little bit more interesting
23:31:00 <drogersuk> ...you can define a stream, it could be optional or could be null
23:31:08 <drogersuk> you can enable all these operations (existing methods on subtlecrypto) to be streamable
23:31:30 <drogersuk> ..(refers to email to the list on 23/04)
23:32:06 <rsleevi> http://lists.w3.org/Archives/Public/public-webcrypto/2013Apr/0145.html
23:33:01 <drogersuk> Israel walks through the steps
23:33:39 <drogersuk> ...you can continuously process data and chain streams and arraybuffers together nicely
23:34:11 <drogersuk> karen asks if you keep the same crypto operators
23:34:52 <drogersuk> IH: yes, (shows processStream)
23:35:09 <drogersuk> ..you would also have your XHR which would let you know when you're done
23:36:00 <drogersuk> for encrypting, decrypting, signing, verifying and the digest, they could also be ArrayBufferView
23:36:16 <drogersuk> with the media source extensions, we do the same thing
23:36:32 <drogersuk> ...this is a pattern we follow in existing specs.
23:37:21 <drogersuk> ..the proposal is to overload - there are different ways we can do this
23:37:59 <drogersuk> karen asks if you can overload in JavaScript, ..(we are faking it essentially :-)
23:38:32 <drogersuk> ..this allows you to expand it and do what you want to do (for example in the Stream examples shown
23:38:53 <drogersuk> ...one of the more interesting ones is - today arraybufferview is defined as a return type
23:39:16 <drogersuk> ArrayBufferView is intended as a type
23:40:31 <drogersuk_> drogersuk_ has joined #crypto
23:42:11 <drogersuk__> drogersuk__ has joined #crypto
23:43:05 <drogersuk__> ..the only different thing we added here was the notion of getting the taglength but there is no way to get the tag
23:43:40 <drogersuk__> RS: Until you all finish you haven't got an authentication tag
23:43:55 <drogersuk__> ..we ended up appending it
23:44:04 <drogersuk__> so when you finish you have the tag appended to it
23:45:13 <drogersuk__> RS: explains that you don't want 10MB blocks of text / cipher / plaintext
23:45:45 <drogersuk__> ..(explains this was related to issue-18 - once you have read data you can drop it
23:46:13 <drogersuk__> ..there is a potential spec issue about how we handle intermediate results
23:46:20 <drogersuk__> IH: Yes that's a good point
23:47:06 <rsleevi> q+
23:47:12 <drogersuk__> IH concludes by saying this is what we have been evaluating
23:47:17 <virginie> q?
23:47:25 <rsleevi> ISSUE-18?
23:47:25 <trackbot> ISSUE-18 -- Should it be possible to perform CryptoOperations as a 'streaming' operation with URI semantics? -- closed
23:47:25 <trackbot> http://www.w3.org/2012/webcrypto/track/issues/18
23:47:48 <drogersuk__> RH: This was previously in issue-18, a lot of these things make sense
23:48:04 <drogersuk__> ..I realise that Microsoft have already implemented this in IE10
23:48:18 <drogersuk__> .. the couple of concerns I raised were timing and deliverables
23:48:42 <drogersuk__> ..another concern related to the whole thing about how we handle the progressive enc/decryption
23:48:47 <drogersuk__> ..size of blocks etc
23:49:10 <drogersuk__> ..the proposal for this will likely impact the proposals around the futures API (being discussed tomorrow)
23:49:30 <drogersuk__> ...createobjecturl is complete hell and would be even worse with crypto
23:49:41 <drogersuk__> (changes JavaScript object into reference)
23:50:06 <drogersuk__> ...but you lose ability for garbage collection (pinning into memory), you're not sure when you're done
23:50:18 <drogersuk__> ...lots of problems how to do that in File API
23:50:34 <drogersuk__> IH: With blobs, you're right there are all kinds of issues
23:50:41 <drogersuk__> ...difference between blobs and streams
23:50:55 <drogersuk__> ..to the extent that we have to solve how to deal with issues like stream to url
23:51:01 <drogersuk__> ..hasn't really been dealt with
23:51:08 <drogersuk__> ..long term we can deal with that
23:51:22 <drogersuk__> ..in the short term we can get a lot of benefit from
23:51:44 <drogersuk__> RS: This was the huge appeal from ISSUE-18
23:52:05 <drogersuk__> ...in this API model you're continuing to make round trips
23:52:14 <drogersuk__> ...not sure how much data should be chunking
23:52:20 <drogersuk__> ..streams does
23:52:34 <drogersuk__> ...need to consider this all
23:52:49 <drogersuk__> ..returning ArrayBuffer, could be just an oversight
23:53:18 <vgb> vgb has joined #crypto
23:53:20 <drogersuk__> ..taking the input though - two bugs with File API, issues with XHR around ArrayBuffer / ArrayBufferView slicing
23:53:27 <jmackay> jmackay has joined #crypto
23:53:32 <drogersuk__> ..probably can continue this discussion off-list
23:53:38 <virginie> q?
23:53:46 <virginie> ack rsleevi
23:53:53 <drogersuk__> IH: internally it's not really immutable
23:54:04 <drogersuk__> ...it's still the whole object is changing
23:54:07 <drogersuk__> ..same construct
23:54:24 <drogersuk__> RS: historic issue is we wanted blobs and ArrayBuffers
23:54:32 <drogersuk__> ... when you call slice it needs to make a copy
23:54:38 <rbarnes> rbarnes has joined #crypto
23:54:41 <drogersuk__> ..and copies bytes and returns copies of bytes
23:55:05 <drogersuk__> ..with an ArrayBuffer you have to copy the number of bytes you sliced
23:55:48 <drogersuk__> ...(continued discussion on dealing with ArrayBuffer and ArrayBufferView as a whole, being the same)
23:56:30 <drogersuk__> RS: Seems reasonable syntactic sugar
23:57:07 <rsleevi> ACTION: rsleevi to update result to be ArrayBuffer than ArrayBufferView
23:57:07 <trackbot> Created ACTION-87 - Update result to be ArrayBuffer than ArrayBufferView [on Ryan Sleevi - due 2013-04-30].
23:57:22 <rsleevi> ACTION: rsleevi to review syntactic sugar overloads for taking (ArrayBuffer and ArrayBufferView)
23:57:22 <trackbot> Created ACTION-88 - Review syntactic sugar overloads for taking (ArrayBuffer and ArrayBufferView) [on Ryan Sleevi - due 2013-04-30].
23:57:58 <rsleevi> ACTION: rsleevi and israelh to work more on Streams API in joint with Futures API
23:57:58 <trackbot> Created ACTION-89 - And israelh to work more on Streams API in joint with Futures API [on Ryan Sleevi - due 2013-04-30].
23:58:59 <drogersuk__> HH: proposes that we take Mark's discussion tomorrow
23:59:15 <drogersuk__> VG: Mark is on his way to the meeting now
23:59:28 <drogersuk__> ..9-10:30 will be use cases (Arun)
23:59:40 <drogersuk__> ..then Robin Berjon is coming to talk about the testing framework
23:59:51 <drogersuk__> ..then cert discussion